Request for reviews (XS): 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use
vladimir.kozlov at oracle.com
Tue Nov 8 12:35:42 PST 2011
Christian Thalinger wrote:
> On Nov 8, 2011, at 7:52 PM, Tom Rodriguez wrote:
>> On Nov 8, 2011, at 10:24 AM, Christian Thalinger wrote:
>>> On Nov 8, 2011, at 7:12 PM, Vladimir Kozlov wrote:
>>>> 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.
> Yeah, right. I just wanted to use Bytecode_invoke::is_invokedynamic.
> -- Chris
>> 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?
>>> -- Chris
>>>> Christian Thalinger wrote:
>>>>> 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use
>>>>> 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.
More information about the hotspot-compiler-dev