Thread by @denis_makogon

#JavaTuesdayThread
I’ve been patiently waiting for JEP 429 publishing with my fingers crossed for quite a while since JEP 425 appeared in a public space (although my story with Project Loom is longer than you can imagine). So, today’s topic is - extent-local variables. #Java

When we started talking about virtual threads the question we've been asked is whether virtual threads are like the old ones. The answer was YES, however, some techniques used to organize the data flow around platform threads may not be valid (but working) for virtual threads.

By saying “some” we’re mostly pointing to thread locals. As you you know, it’s possible to start over 10M threads for nothing while it’s not the same for platform threads because the JVM, like the other processes, has a thread count limitation it cannot surpass.

Even before virtual threads, thread locals have a few problems like:
- Unconstrained mutability - whoever can get() can do set() either; [1/3]

- Unbound lifecycle - they exist through a thread lifecycle or up until remove() invocation, which can lead to continuous memory leaks; [2/3]

- Expensive inheritance - in fact, thread local isn’t local to one thread, but available to child threads which leads to a significant memory footprint [3/3]

With virtual threads the situation is a bit different, even if a thread local isn’t removed, the cleanup will be done shortly because virtual threads are meant to be short-lived.

But still, thread-local variables have more complexity than is usually needed for sharing data, and significant costs that cannot be avoided.

So, there has to be a way to maintain immutable and inheritable per-thread data for thousands or millions of virtual threads. Any data shared through the thread-bound variable should become unusable once the method that initially shared the data is finished.

The requirement for the technology we've been looking for is to replace thread-local variables that should prevent unconstraint mutability as well as unbound lifetime.

That’s what “extent-local variables” going to be, it will allow data to be safely and efficiently shared between components in a large program without resorting to method arguments. download.java.net/java/early_acc…

Unlike a thread-local variable, an extent-local variable is written once and is then immutable, and is available only for a bounded period during the execution of the thread.

The idea of extent-locals to limit the period of time through which an underlying runnable object can access immutable value:

The immutability of extent-local variables means that a caller can use an extent-local variable to reliably communicate a constant value to its callees in the same thread.

However, there are occasions when one of the callees might need to use the same extent-local variable to communicate a different value to its own callees in the thread.

The “Extent-Locals” API proposes two public classes like “ExtentLocal” and “ExtentLocal.Carrier” - the first one designed to bind a value to an extent-local variable while the second one stands for the execution of a callee (through Runnable or Callable).

Interesting that it’s possible to rebind the value of an extent-local variable from another thread, however, the scope of rebound immutable value, again, is limited to the scope of a callee which means that the original value wouldn’t change to whoever will request that value.

The best way to showcase the extent-local variables inheriting is to combine them with structured concurrency blocks (JEP 428) because a thread that will allocate a new scope will eventually call a "fork" that will spawn a child thread that will inherit parent extent-locals.

StructuredTaskScope::fork ensures that the binding of the extent-local variable will make in the request-handling thread is automatically visible in the child thread.

The fork/join model offered by StructuredTaskScope means that the value bound by ExtentLocal::where has a determinate lifetime.

It means that an extent-local variable is available to the child thread while it is running, and scope.join() ensures that child threads terminate and thus no longer use it. This avoids the problem of unbounded lifetimes seen when using thread-local variables.

So, you see, extent-local variables are likely to be useful and preferable in many scenarios where thread-local variables are used today like state propagation, but unlike thread locals, extent-local variables are immutable to however consume.

Probably the most important fact is that a thread-pool problem that is specific to thread-locals (the content of a thread-local variable may not be removed at any time) is not a thing to an extent-locals because the lifecycle of an owner virtual thread is meant to be short...

...and virtual threads are not subject to pooling.