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