Thread-local successor for object pooling

[Glavo]

I'm wondering if we can create a new ThreadLocal replacement for virtual
threads?

I call this alternative PlatformThreadLocal. It differs from ThreadLocal in
that it is based on platform threads and can be shared among multiple
virtual threads.

If we don't want to share it between virtual threads, we need to call a
method called 'pin' to get the value and call the 'unpin' method when we
are done using it (or use the try-with-resources statement):

static  PlatformThreadLocal<SomeValue> cache =
PlatformThreadLocal.withInitial(/* heavy initialization */);

void foo() {
    try (ThreadLocal<SomeValue>  pinnedCache = cache.pin()) {
        SomeValue value =  pinnedCache.get();
        // use the value
    }
}


For platform threads, the 'pin' method should return the 'cache' itself;

For virtual threads, the 'pin' method will pin the value of the platform
thread on the current virtual thread, until the 'unpin' method is called.
During this time, if another virtual thread running on the same platform
thread tries to pin the value, it will get a new ThreadLocal value
associated with the current virtual thread.



On Mon, Oct 31, 2022 at 6:21 PM Volkan Yazıcı <volkan at yazi.ci> wrote:

> Hello,
>
> Log4j heavily relies on thread-locals (TLs) for object pooling. This
> becomes of particular importance for caching and garbage-free logging
> purposes. With JEP 425 (Virtual Threads), this becomes problematic due to
> two main issues:
>
> 1. TLs on vthreads yield no allocation benefits since vhtreads are
> short-lived. On the contrary, it becomes a redundant memory cost due to the
> excessive vthread count. In this case, Log4j still works, though slower and
> with increased memory footprint.
>
> 2. TL mutation can be disabled for vthreads. In this case, Log4j doesn't
> work, since TL setters throw UnsupportedOperationException.
>
> Users experimenting with Java 19 have already started reporting these
> issues[1]. JEP 429 (Scoped values) might be the answer to our questions,
> yet I have the impression that there will be a time gap between the GA
> releases of vthreads and SVs. Hence I would like to know what is the best
> angle to address this problem using the tooling that will be provided by
> JEP 425.
>
> I believe our use cases apply to many other major libraries in the wild. I
> would appreciate it if OpenJDK developers can help us with determining a
> way forward.
>
> Kind regards.
>
> [1] https://issues.apache.org/jira/browse/LOG4J2-3622
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20221101/36c4696b/attachment-0001.htm>