RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3]

Alan Bateman alanb at openjdk.org
Tue Nov 8 08:01:28 UTC 2022


On Tue, 8 Nov 2022 04:23:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Note the loader involved need not be our own default platform loader and we don't know how a custom system loader might operate. The specification for this says nothing about thread-safety, nor that the VM will do any locking, so I think it is okay to remove it - but it is a change in behaviour that should be documented by a CSR request.

In that configuration, the custom system class loader will be created with the app class loader as its parent. It's still the app class loader that loads from the class path and it will be the app class loader's appendToClassPathForInstrumentation method that is called (there's no equivalent for custom system class loaders). I would hope there are tests for this but the discussion makes me wonder what SystemDictionary::java_system_loader() returns, esp. given a custom class loader won't be created until initPhase3.

-------------

PR: https://git.openjdk.org/jdk/pull/11023


More information about the serviceability-dev mailing list