RFR: 8355938: Addressed rare lost unpark bug 8074773 by pre-loading LockSupport.class

[Alan Bateman]

On Tue, 29 Apr 2025 17:02:38 GMT, kabutz <duke at 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.

Might be a bit premature to change these classes. I think the starting point is to page in the issue from 2015 so there is a clearer picture of where the parking permit is consumed. Was it always CHM used by parallel capable class loaders? It might be that we should preload LockSupport in initPhase3 but I think it requires more details on the original issue before doing anything.

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

PR Comment: https://git.openjdk.org/jdk/pull/24952#issuecomment-2839633607