-
CSR
-
Resolution: Approved
-
P4
-
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.
- csr of
-
JDK-8296472 Remove ObjectLocker around appendToClassPathForInstrumentation call
- Resolved