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

[Vladimir Ivanov]

David,

Thank you for the review.

On 8/21/13 4:52 AM, David Holmes wrote:
> Hi Vladimir,
>
> The initialization code location looks good to me.
>
> I presume the shutdown hook in the test (another reason this needs to be
> othervm!) is to see a dump via ctrl-C if there is a hang?
Yes, exactly.

Best regards,
Vladimir Ivanov

>
> David
>
> On 21/08/2013 3: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