Question on Project Loom and motivation to introduce ScopedValues

Francesco Nigro nigro.fra at
Mon Oct 9 07:14:24 UTC 2023


I have opened which
has been fixed by Mario Fusco, a Red Hat mate of mine.
In the issue I have explained few implementation strategy which I strongly
recommend, for similar use cases, but I didn't point the best strategy
overall: some of these cases uses pooling intermediate objects as a
solution to a problem they have created themselves.
For example, intermediate encoding steps which requires allocating byte[]
of unknown capacity upfront (If not by performing an estimation pass
upfront, which could be O(N)) were solved by a single pooled intermediate
byte[] allocation (via thread local) which proved to be a difficult match
for ScopedValue (as expected), but if we have a "linked arrays of byte[]"
structure enabling allocations in small chunks, it can be more GC friendly
than the usual ArrayList-like strategies and probably (to be measure, as
usual) won't requires any form of pooling, although we would allocate an
additional intermediate object.

Hope this helps,


Il lun 9 ott 2023, 08:39 Alan Bateman <Alan.Bateman at> ha scritto:

> 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:
> 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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the loom-dev mailing list