Question on Project Loom and motivation to introduce ScopedValues

[Francesco Nigro]

Hi,

I have opened https://github.com/FasterXML/jackson-core/issues/919 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,

Franz

Il lun 9 ott 2023, 08:39 Alan Bateman <Alan.Bateman at oracle.com> 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:
>    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/567aa649/attachment-0001.htm>