On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore <cole...@openjdk.org> wrote:
>> This patch moves the acquisition of the boot class loader lock out of the >> JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one > additional commit since the last revision: > > really revert the file I checked the JLPIS agent (= j.l.instrument implementation) with a custom system class loader that doesn't define a appendToClassPathForInstrumentation method and it isn't handled correctly. The right behavior should be for AddToSystemClassLoaderSearch to throw UOE but instead it aborts the VM. So I think we'll create a JBS issue for that. If the custom system class loader does define appendToClassPathForInstrumentation then it will be called, it's just not possible for it to delegate it to the application class loader's appendToClassPathForInstrumentation. It's very possible this will lead to some anomalies as the defining class loader for the classes on the original class path will be the app class loader but any classes added by the agent at runtime (after startup) will likely be the custom system class loader. This is Java agents as opposed to JVMTI agents but it does suggest that the combination of custom system class loader and agents augmenting the class path at runtime is not well tested. So ObjectLocker or not, it is unlikely to be detected by any tests. ------------- PR: https://git.openjdk.org/jdk/pull/11023
