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

[Vladimir Kozlov]

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