RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call
Alan Bateman
alanb at openjdk.org
Mon Nov 7 18:36:33 UTC 2022
On Mon, 7 Nov 2022 18:11:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java line 204:
>>
>>> 202: * @see java.lang.instrument.Instrumentation#appendToSystemClassLoaderSearch
>>> 203: */
>>> 204: synchronized void appendToClassPathForInstrumentation(String path) {
>>
>> We might not need this. appendClasspath is thread safe so it's okay for several agents calling appendToSystemClassLoaderSearch at around the same time. I don't think it needs to sycnrhonize with anything else.
>
> I traced it down to this: Is this why it's already synchronized ?
> appendClassPath -> ucp.addFile -> addURL
> public synchronized void addURL(URL url) {
> if (closed || url == null)
> return;
> synchronized (unopenedUrls) {
> if (! path.contains(url)) {
> unopenedUrls.addLast(url);
> path.add(url);
> }
> }
> }
Yes, URLClassPath is already synchronized. I'm not 100% sure why the ObjectLocker is there but it's possible to pre-dates parallel capable class loaders so it dates from a time when findClass/loadClass were synchronized on "this".
-------------
PR: https://git.openjdk.org/jdk/pull/11023
More information about the core-libs-dev
mailing list