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.
-------------
Commit messages:
- Addressed rare lost unpark bug 8074773 by pre-loading LockSupport.class
Changes: https://git.openjdk.org/jdk/pull/24952/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24952&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8355938
Stats: 22 lines in 4 files changed: 21 ins; 1 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/24952.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24952/head:pull/24952
PR: https://git.openjdk.org/jdk/pull/24952
