Request for reviews (XS): 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use

[Tom Rodriguez]

On Nov 8, 2011, at 10:24 AM, Christian Thalinger wrote:

> 
> On Nov 8, 2011, at 7:12 PM, Vladimir Kozlov wrote:
> 
>> Christian,
>> 
>> You recently fixed other code to avoid check bytecode directly. So should you use is_method_handle_invoke() here? Or it is not correct for this place?
> 
> I wanted to do that but then I noticed that there is no easy way to get a methodHandle out of a ciMethod and left it as it is.  If you know of a good way let me know and I will change it.

I don't think you want to use is_method_handle_invoke in this code.  It's explicitly interested in what kind of call site is being used so that it can emit the proper kind of guard.

In the failing case what invoke bytecode is being used?  invokevirtual?  Why would some call sites that invoke an MH used invokevirtual and others use invokespecial?

tom

> 
> -- Chris
> 
>> 
>> Thanks,
>> Vladimir
>> 
>> Christian Thalinger wrote:
>>> http://cr.openjdk.java.net/~twisti/7087727/
>>> 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use
>>> Reviewed-by:
>>> The flag setting ScavengeRootsInCode=2 causes the JIT to inline more
>>> constants.  This is generally a good thing for performance, but can
>>> cause bugs in compiled code.
>>> The test case has a code pattern that looks similar to the
>>> selectAlternative idiom but boils down to a different invoke bytecode
>>> (invokevirtual in that case).  The current code in
>>> PredictedDynamicCallGenerator::generate checks for invokespecial
>>> (which is used by selectAlternative) and so code for invokedynamic is
>>> generated (in non-debug builds) which eventually leads to a crash.
>>> src/share/vm/opto/callGenerator.cpp
>