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

kabutz duke at openjdk.org
Mon May 12 13:59:57 UTC 2025


On Fri, 9 May 2025 06:37:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> No, it will still uses synchronized if there is contention and this will not consume the park permit when it's a virtual thread. Im not sure if Heinz ran into an issue, or just remember the issue from 2015, Heinz?

I saw this comment in the JavaDoc of LockSupport: https://github.com/openjdk/jdk/blob/7ae52ce572794f9d17446c66381f703ea1bb8b7c/src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java#L135 

I then searched through the JDK classes and the only ones that used LockSupport and that did not have the static {var clazz = LockSupport.class;} were the newer classes that arrived with Java 19, plus also Exchanger (which may have been an oversight).

If this is no longer an issue, and we are 100% sure of that, then we can perhaps change the example to not have that static loader?

I have not tried to reproduce the bug, and from what Martin Buchholz described it is extremely elusive.

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

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


More information about the nio-dev mailing list