Thread-local successor for object pooling
Alan Bateman
Alan.Bateman at oracle.com
Wed Nov 2 06:49:20 UTC 2022
On 02/11/2022 00:03, Carter Kozak wrote:
> :
>
> This is an interesting point. I'm not sure I understand why the
> introduction of virtual threads is the best place to make the
> ThreadLocal language feature configurable, but I'd appreciate
> additional context.
> The JEP describes the motivation for the dynamic configuration of
> ThreadLocals, as well as an alternative (jep-429 scoped values),
> however the behavior seems (to an outsider) to oppose the higher-level
> design of virtual threads which are meant to be otherwise a drop-in
> replacement for platform threads. I'd much rather fail predictably (or
> in a way the compiler can warn me about) rather than when a legacy
> function compiled with jdk1.5 executes on a particular type of thread.
Virtual threads are not meant to be a drop-in replacement like this, you
wouldn't want to end up pooling virtual threads. As I said, the question
on whether we should continue to allow opt-out of thread locals when
creating threads is an issue where more feedback is required. Right now,
if you opt-out then then some code that using TLs will fail at run-time,
which of course is not desirable. Another option on the table at the
time was for TL.set (the only method that throws) to be a no-op so that
TL.get always returns the initial value. Related is that the option to
opt out of inheriting the initial value of inhertable-TLs has been there
since Java 9. Inheritable TLs aren't widely used of course but it is an
example of something related that is not limited to the thread kind.
I don't think a warning at compile time is feasible here as libraries on
the class or module path will be a mix of class file versions. The code
that creates the threads may be a different library to code that is
making a lot of use of TLs.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20221102/8224550d/attachment.htm>
More information about the loom-dev
mailing list