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

David Holmes david.holmes at oracle.com
Tue Aug 20 17:52:33 PDT 2013


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?

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


More information about the hotspot-runtime-dev mailing list