On Wed, 26 Feb 2025 19:46:41 GMT, Alan Bateman <al...@openjdk.org> wrote:
> Data structures that are accessed by both virtual threads and their carriers
> require the virtual thread to pin the continuation to avoid potential
> deadlock. A deadlock can arise when a virtual thread is preempted, is
> selected and scheduled to be the next owner of the lock/resource, but can't
> execute because all carriers are blocking on the same lock/resource. There
> are a small number of places that need to pin. One that was missed is the the
> notification to the thread container when threads are started or terminate.
> This is not currently an issue at this time but it is a potential hazard for
> ongoing and future work that will add further scheduling points to the code.
> Continuation.pin/unpin have intrinsics since JDK-8338745, and Continuation is
> initialized early in startup. Finally, the changes have been in the loom repo
> for several months with no issues.
>
> Testing tier1-5, quick statup/footprint, noreg-hard
src/java.base/share/classes/jdk/internal/vm/ThreadContainer.java line 97:
> 95: public final void add(Thread thread) {
> 96: // Prevent a virtual thread from being preempted as this could
> potentially
> 97: // deadlock with a carrier is removing a virtual thread from the
> container
Is there a typo in this sentence? Should "with a carrier" have been "when a
carrier ..." ? Similar comment in the remove(...) method too.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23810#discussion_r2084191952
