Huh...I wonder if I never added it? I know we had discussed it, but I don't remember what we decided. Can you blame the -h change and try to sort it out?

@headius it seems you added it back in 309576b seems accidental, as the commit message doesn't mention it

Ok, then I guess we don't have that flag and should remove the doco :-)

We can debate separately whether we should add it. @enebo?

I actually kind of liked to have that flag available, if I may join in :) But nothing too important :)

I don't like it as a flag and prefer a property and ultimately it is just an aggregate flag for several individual properties. Invokedynamic is an implementation detail you can toggle on or off, but for it to be at the same level of an option I think it needs to:

1. Be well known as a feature
2. Have a reason to easily be able to toggle it on or off

For 1, there is a subset of people who know about it but ultimately I think our JIT should be deciding how to use invokedynamic. Had there been no problems with it from a warmup or deoptimization (now mostly fixed) position then we would not even be having this discussion (it would always be on).

For 2, we currently have a reason for letting people enable ofdisable aspects of indy but it is a tunable. I suspect as a tunable you might not have this as an all or nothing feature unless the app is small. You might elect to enable some of the invokedynamic options until you get the performance/warmup which works for you. If this is the case, then you will be mostly tweaking the various indy properties. Having a main turn it all on property is cool to me though (it is a good starting point for tuning).

So my bias is towards leaving it only as a property and hoping that JVM fixes the warmup issues we still have with invokedynamic. In the future, I am also hoping IR will inform important sites to use indy and backoff on less hot sites with non-indy. This does not really even fit with the idea of properties; but I think it gives an idea as to why I don't think it is an option. This idea of selectively using indy is also sort of a backup plan if indy never warms up fast enough for us. We can still use indy but not enough for it to destroy warmup time.

Yeah, I agree with Tom. Or rather, I disagree, but it's because I want --indy for my local benchmarking/testing purposes. That's not a good enough reason to pollute our toplevel flags with yet one more :-)

I will fix up the doco.