On Tue, 29 Apr 2025 17:02:38 GMT, kabutz <d...@openjdk.org> wrote:
> In 2015, Google discovered a rare disastrous classloading bug in first call
> to LockSupport.park() that occurred in the AppClassLoader using the Java 7
> ConcurrentHashMap, which used ReentrantLock for the synchronization.
>
> Since then, the recommended fix for this bug seems to be this code snippet in
> any class that directly calls LockSupport.park():
>
>
> static {
> // Prevent rare disastrous classloading in first call to LockSupport.park.
> // See: https://bugs.openjdk.java.net/browse/JDK-8074773
> Class<?> ensureLoaded = LockSupport.class;
> }
>
>
> Since the bug was logged, we have seen new classes in the JDK that call
> LockSupport.park(), but that do not have this code snippet. For example:
>
> sun.nio.ch.Poller
> jdk.internal.misc.ThreadFlock
> java.util.concurrent.ThreadPerTaskExecutor
>
> It should probably also be in:
>
> java.util.concurrent.Exchanger
>
> Considering how hard this bug is to detect and solve, it would probably be
> safer to add the code snippet into these newer classes.
The bug description seems like it is a fault in the JVM implementation - if
that is the case, a core library bypass is unreliable, as such faults might
happen to other classes and cause other consequences; and we might need to fix
it from the VM runtime or compiler side, as the original report implies.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2839922275
