On Mon, 12 May 2025 14:01:16 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 > > Alan Bateman has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains 10 additional > commits since the last revision: > > - Fix/improve comment > - Merge branch 'master' into JDK-8350765 > - Merge branch 'master' into JDK-8350765 > - No need to used qualified name > - Merge branch 'master' into JDK-8350765 > - Update > - Merge branch 'master' into JDK-8350765 > - Add method to ContinuationSupport > - Missing / > - Initial commit Thank you for the update Alan. The change looks reasonable to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23810#pullrequestreview-2836451768
