Thread-local successor for object pooling

[Alan Bateman]

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>