Join GitHub today
Was the --indy cli option removed? (126.96.36.199) #2231
just wondering if I'm extra ordinarily stupid right now or if the
Cheers + thanks,
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:
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.