RFR (XS): 8022595: JSR292: deadlock during class loading of MethodHandles, MethodHandleImpl & MethodHandleNatives

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Aug 20 13:07:28 PDT 2013


On 8/20/13 12:23 PM, Vladimir Ivanov wrote:
> Yes, the test fails pretty reliably w/o the fix.

Good. And Coleen has valid point about CHECK_0.

Thanks,
Vladimir


>
> Best regards,
> Vladimir Ivanov
>
> On 8/20/13 10:23 PM, Vladimir Kozlov wrote:
>> On 8/20/13 11:16 AM, Vladimir Ivanov wrote:
>>> Vladimir,
>>>
>>> Thanks for the review.
>>>
>>> I specified /othervm, since I want to provoke a deadlock during JSR292
>>> core classes initialization. If the classes are already initialized, the
>>> test is meaningless.
>>
>> Okay. Did you reproduce the failure with VM without fix and this test?
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 8/20/13 10:00 PM, Vladimir Kozlov wrote:
>>>> Looks fine to me.
>>>>
>>>> You don't need /othervm in the test if you don't use any flags.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 8/20/13 10:05 AM, Vladimir Ivanov wrote:
>>>>> http://cr.openjdk.java.net/~vlivanov/8022595/webrev.01/
>>>>> 201 lines changed: 201 ins; 0 del; 0 mod;
>>>>>
>>>>> Some classes in j.l.invoke have circular dependencies between them
>>>>> which
>>>>> leads to deadlocks during class initialization when multiple threads
>>>>> exercise JSR292 functionality.
>>>>>
>>>>> JSR292 core classes are among "well-known" classes to VM and they are
>>>>> preloaded during VM startup (see
>>>>> SystemDictionary::initialize_preloaded_classes). However, it doesn't
>>>>> force preloaded classes to be initialized (doesn't execute static
>>>>> initializers). Thus, these classes should be explicitly
>>>>> pre-initialized
>>>>> in order to avoid deadlocks.
>>>>>
>>>>> Based on my observations of possible deadlock scenarios, I chose 3
>>>>> classes to pre-initialize:
>>>>>      - MethodHandle
>>>>>      - MemberName
>>>>>      - MethodHandleNatives
>>>>>
>>>>> I placed the code right after compilers initialization because during
>>>>> method resolution for signature polymorphic intrinsics, compilation
>>>>> tasks are issued (see SystemDictionary::find_method_handle_intrinsic
>>>>> for
>>>>> details) and they are missed if compiler subsystem isn't ready yet.
>>>>>
>>>>> Testing: failing test, regression test, JPRT, jdk/test/j/l/invoke,
>>>>> vm.mlvm.testlist, octane.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov


More information about the hotspot-compiler-dev mailing list