[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-nio-dev
Subject:    Integrated: 8291897: TerminatingThreadLocal(s) not registered from virtual thread(s)
From:       Peter Levart <plevart () openjdk ! org>
Date:       2022-08-08 12:41:51
Message-ID: fADsMdszkdzOld6umODmseDURQCJwfiRQc7obfvyLJI=.c09d0bf9-a8e7-45b0-aa68-4a27d33cfc51 () github ! com
[Download RAW message or body]

On Thu, 4 Aug 2022 10:57:53 GMT, Peter Levart <plevart@openjdk.org> wrote:

> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when \
> used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and \
> NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are \
> not registered with the carrier thread for the cleanup. The fix introduces an \
> internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods \
> to use current thread's carrier thread as the source of ThreadLocalMap instead of \
> current thread itself (if it is a VirtualThread for example). \
> TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only \
> per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in \
> various places to access a carrier-thread value of given ThreadLocal has been \
> replaced by public API calls and the use of CarrierThreadLocal instead of plain \
> ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API \
> methods, but only for that. Would someone be tempted to use JavaLangAccess methods \
> directly, they now require CarrierThreadLocal argument to guard against missuses. \
> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values \
> bound to a particular carrier thread is now implemented conveniently  with a \
> CarrierThreadLocal. The test is expanded with a case that demonstrates a situation \
> where a carrier thread is terminated. Since it must wait for 30 seconds for that to \
> happen, only one of the test cases is performed in this mode. The correct logic of \
> TerminatingThreadLocal is still verified with all test-cases using platform threads \
> that can be terminated more rapidly.

This pull request has now been integrated.

Changeset: 861cc671
Author:    Peter Levart <plevart@openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/861cc671e2e4904d94f50710be99a511e2f9bb68
                
Stats:     262 lines in 9 files changed: 196 ins; 12 del; 54 mod

8291897: TerminatingThreadLocal(s) not registered from virtual thread(s)

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk/pull/9743


[prev in list] [next in list] [prev in thread] [next in thread]