Question on Project Loom and motivation to introduce ScopedValues

[Andrew Haley]

On 10/8/23 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?

As with everything else in the Java library, it's a compromise.

We need to be able to bind and unbind a scoped value with small cost,
and we need to be able to share a set of bindings between threads. If
the set of bindings were stored in a mutable data structure such as a
HashMap, then that HashMap would need to be cloned whenever it was
shared. So we need a map that can be shared without cloning all of it.

There's not a great many immutable data structures (see
https://en.wikipedia.org/wiki/Persistent_data_structure) to choose
from. We did consider an immutable variant of Bagwell's Hash Array
Mapped Trie, but updates are expensive. There's also "Concurrent Tries
with Efficient Non-blocking Snapshots",
http://aleksandar-prokopec.com/publications/concurrent-tries-with-snapshots/
but the sharing cost is significant.

>     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.

It was! We realized that, semantically, the properties of scoped
values are so different from those of thread-local variables that to
use the same API would be misleading. In particular, an immutable
subclass of ThreadLocal would fail the principle of Liskov
substitutability, with all of the nasty results you'd expect.

Over the course of the project we explored the design space pretty
thoroughly, and most of the possibilities, including this one, were
prototyped. Adding an API (with restrictions) to ThreadLocal
constrained the scoped-value implementation and the API, leading to
intolerable compromises in robustness, readability, efficiency, and
maintainability.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671