On Mon, 12 May 2025 09:01:34 GMT, Jaikiran Pai <[email protected]> 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.
You are right, there is a pre-existing typo in that comment (the sentence was
copied to here from RQ).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23810#discussion_r2084260621
