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 This pull request has now been integrated. Changeset: fa419489 Author: Alan Bateman <al...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/fa419489d3769a989ee5bd948eeda0ed9be071e2 Stats: 94 lines in 6 files changed: 50 ins; 25 del; 19 mod 8350765: Need to pin when accessing thread container from virtual thread Reviewed-by: vklang, jpai ------------- PR: https://git.openjdk.org/jdk/pull/23810
