<div dir="auto">Hi, <div dir="auto"><br></div><div dir="auto">I have opened <a href="https://github.com/FasterXML/jackson-core/issues/919">https://github.com/FasterXML/jackson-core/issues/919</a> which has been fixed by Mario Fusco, a Red Hat mate of mine.</div><div dir="auto">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.</div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Hope this helps,</div><div dir="auto"><br></div><div dir="auto">Franz</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il lun 9 ott 2023, 08:39 Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
  <div>
    On 08/10/2023 19:41, Ilya Starchenko wrote:<br>
    <blockquote type="cite">
      
      <div dir="ltr">Hello loom-dev team,
        <div><br>
        </div>
        <div dir="ltr">Firstly, I'd like to express my appreciation for
          your work on Project Loom.</div>
        <div dir="ltr">I have a couple of questions regarding
          ThreadLocal and the motivation behind introducing ScopedValues
          that I hope you can clarify for me.</div>
        <div dir="ltr"><br>
        </div>
        <div dir="ltr">
          <ol style="margin:0px" dir="ltr" start="1">
            <li>I'm starting to deep how ScopedValues works(ref: <font color="#419cff"><span><a href="https://github.com/openjdk/jdk/blob/dc4bc4f0844b768e83406f44f2a9ee50686b1d9d/src/java.base/share/classes/java/lang/Thread.java#L302" target="_blank" rel="noreferrer">https://github.com/openjdk/jdk/blob/dc4bc4f0844b768e83406f44f2a9ee50686b1d9d/src/java.base/share/classes/java/lang/Thread.java#L302</a></span></font>) 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?</li>
          </ol>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div dir="ltr">
          <ol style="margin:0px" dir="ltr" start="1">
            <li>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?</li>
          </ol>
          <br>
        </div>
      </div>
    </blockquote>
    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.<br>
    <br>
    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. <br>
    <br>
    For other shared objects (esp. those with native resources) then it
    you may have to look at alternative ways to cache.<br>
    <br>
    -Alan<br>
    <br>
    [1] <a href="https://openjdk.org/jeps/446" target="_blank" rel="noreferrer">https://openjdk.org/jeps/446</a><br>
  </div>

</blockquote></div>