Request for review (S): 7042122: JSR 292: adjust various inline thresholds for JSR 292 API methods and method handle adapters

Rémi Forax forax at
Fri May 6 08:56:00 PDT 2011

On 05/06/2011 03:49 PM, Christian Thalinger wrote:
> On May 5, 2011, at 10:29 PM, Tom Rodriguez wrote:
>>>> The reason I came up with something like band-aid fix is because I didn't have enough time to do something more sophisticated and we need something that works in Java 7.  JRuby wants to enable invokedynamic by default for the current development version as soon as we have heuristic that makes out-of-the-box performance good enough (reads: equally or better than non-indy).
>>>> Tom, do you have a better idea how we could handle that?
>>> Given where we are I thought your patch was a fine band aid.  I was just a bit leery of adding a real exposed flag before we've really had a chance to make a policy.  If we're fine with potentially abandoning that flag later then I'm fine with adding it.
>> I do have one concrete thought about this but it would require some investigation.  The method handle chains themselves aren't profiled but presumably the base call site is.  Maybe we should be looking back through method handle calls to find the frequency of the base call site and feeding that into the frequent call site logic.
> Yeah, I suppose that's how it should work.  What about this?
> I get the same performance but without any tweaking of any inline thresholds.
> -- Christian

I've just though that because there is no profiling info, a method 
handle constructed
using findVirtual with a receiver that is not bound, by example if the 
receiver is taken as parameter,
will never be de-virtualized.

I wonder if a way to solve that is to generate the code with the 
profiling info like this is done
if tiered compilation is enabled and then to re-optimize the callsite 
using mdo.


More information about the hotspot-compiler-dev mailing list