review for 7050554: JSR 292 - need optimization for selectAlternative

Tom Rodriguez tom.rodriguez at
Thu Jun 2 12:40:32 PDT 2011

Thanks Vladimir and John.


On Jun 1, 2011, at 5:00 PM, Vladimir Kozlov wrote:

> Good.
> Thanks,
> Vladimir
> Tom Rodriguez wrote:
>> On Jun 1, 2011, at 4:38 PM, Vladimir Kozlov wrote:
>>> What about when only one call site could be inlined in bimorhphic case?
>> I considered allowing only one to be inlined but that doesn't really seem to occur.  Since these are method handle chains they should all be constants and each side is method handle and we will pretty much always inline them once we start a chain.  This is really about getting back performance that we lost because of JDK changes more than attempting to do the most optimal thing.  We'll revisit the inlining optimizations after 7 ships.
>> tom
>>> Vladimir
>>> Tom Rodriguez wrote:
>>>> 130 lines changed: 74 ins; 20 del; 36 mod; 4493 unchg
>>>> 7050554: JSR 292 - need optimization for selectAlternative
>>>> Reviewed-by:
>>>> JSR 292 provides a GuardWithTest idiom is allow selection between two
>>>> different method handles based on a boolean test.  In earlier versions
>>>> of the JDK code this was done with a bunch of little wrapper methods
>>>> for different arities.  This resulted in a call site for a each call
>>>> which allowed existing constant folding code to statically bind the
>>>> call sites.  Because this didn't scale it was replaced with a new
>>>> idiom that looks more like (test ? a : b).invoke() which only have a
>>>> single call site.  This interferes with inlining making the code
>>>> perform terribly.  We need a new bimorhphic inline for invokedynamic
>>>> callsites to deal with this.  Without it performance of invokedynamic
>>>> for things like jruby is pretty terrible.  Tested with regression
>>>> tests and jruby tests.
>>>> I also fixed a problem in the shared print compilation code where
>>>> attempting to print zombie for an unloaded nmethod causes a segv
>>>> because the method is NULL.

More information about the hotspot-compiler-dev mailing list