Question on Project Loom and motivation to introduce ScopedValues

[Alan Bateman]

On 08/10/2023 19:41, Ilya Starchenko wrote:
> Hello loom-dev team,
>
> Firstly, I'd like to express my appreciation for your work on Project 
> Loom.
> I have a couple of questions regarding ThreadLocal and the motivation 
> behind introducing ScopedValues that I hope you can clarify for me.
>
>  1. I'm starting to deep how ScopedValues works(ref:
>     https://github.com/openjdk/jdk/blob/dc4bc4f0844b768e83406f44f2a9ee50686b1d9d/src/java.base/share/classes/java/lang/Thread.java#L302) and
>     noticed that ScopedValues' snapshots are placed in the same place
>     as the map of ThreadLocals. However, I'm struggling to grasp why a
>     LinkedList of maps within the Thread field is favoured over a
>     HashMap? I understand that ScopedValues have a concept of scope
>     and are immutable, but I'm curious as to why it wasn't considered
>     to introduce a new API for TL that would incorporate scope and
>     immutability. Are there technical reasons that make ScopedValues
>     superior to TL, or was enhancing ThreadLocal (by adding scope and
>     immutability) not a viable option?
>

It might be best to start with JEP 446 [1] as it provides the motivation 
and all the background reading on this topic, including the options to 
force fit ThreadLocal to do it.



>  1. Many users and libraries use ThreadLocal for object pooling(which
>     can have a major performance impact). Do you have any
>     recommendations for migrating these use cases? Perhaps to some
>     form of global cache?
>
>
It's usually good to re-evaluate as you may find that some of this 
object pooling has a negative impact in 2023. In the JDK we moved 
several usages of ThreadLocal where the caching turned out to hurt rater 
than help performance. It may have helped performance when added many 
years ago but VM/GC has improved significantly in the mean-time.

For mutable objects that are expensive to create but aren't thread safe 
then move to immutable objects if possible. We've seen some success 
moving from ThreadLocal<SimpleDateFormat> to DataTimeFormatter for example.

For other shared objects (esp. those with native resources) then it you 
may have to look at alternative ways to cache.

-Alan

[1] https://openjdk.org/jeps/446
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20231009/eaeec9d3/attachment.htm>