Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8297169

Remove ObjectLocker around appendToClassPathForInstrumentation call

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Approved
    • Icon: P4 P4
    • 20
    • hotspot
    • None
    • behavioral
    • minimal
    • The default system class loader appends to the class path in a thread safe manner. The reliance of undocumented, unspecified JVM synchronization for custom class loader `appendToSystemClassLoaderSearch` seems unlikely.
    • Other
    • Implementation

      Summary

      The JVM will no longer synchronize on the system class loader object before calling appendToClassPathForInstrumentation.

      Problem

      When running an application with a Java agent (e.g. -javaagent:myagent.jar) and a custom system class loader (e.g. -Djava.system.class.loader=MyClassLoader), the Java agent invokes the Instrumentation.appendToSystemClassLoaderSearch method of the custom system class loader to add the JAR file to the custom system class loader's search path. At present the JVM will synchronize on the custom class loader for that Java upcall from the agent, using the internal ObjectLocker mechanism. However, we are trying to eradicate use of this mechanism in the JVM to allow for more flexible locking strategies in the future.

      Solution

      The JVM no longer synchronizes on the custom class loader while calling appendToClassPathForInstrumentation. The appendToClassPathForInstrumentation method in the custom class loader must add to the class search path in a thread-safe manner.

      Specification

      There are no specification changes. This is an unspecified, and undocumented, behaviour that is now changing.

            coleenp Coleen Phillimore
            coleenp Coleen Phillimore
            Alan Bateman, David Holmes
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: