Preload LockSupport.class in classes that use LockSupport

XMLWordPrintable

    • Type: Bug
    • Resolution: Unresolved
    • Priority: P4
    • tbd
    • Affects Version/s: 19, 21, 25
    • Component/s: core-libs
    • None

      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.

            Assignee:
            Heinz Kabutz
            Reporter:
            Heinz Kabutz
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: