<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    On 08/10/2023 19:41, Ilya Starchenko wrote:<br>
    <blockquote type="cite" cite="mid:CAD0tGQuzPF6C3dg4cOr_5cDCNLkP6W0pNdV6Q5iu7iPU3ZkS7Q@mail.gmail.com">
      
      <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 style="--dark-color:
                  var(--NSColor_linkColor);"><a href="https://github.com/openjdk/jdk/blob/dc4bc4f0844b768e83406f44f2a9ee50686b1d9d/src/java.base/share/classes/java/lang/Thread.java#L302" moz-do-not-send="true" class="moz-txt-link-freetext">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" cite="mid:CAD0tGQuzPF6C3dg4cOr_5cDCNLkP6W0pNdV6Q5iu7iPU3ZkS7Q@mail.gmail.com">
      <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 class="moz-txt-link-freetext" href="https://openjdk.org/jeps/446">https://openjdk.org/jeps/446</a><br>
  </body>
</html>