Thread-local successor for object pooling

[Duncan MacGregor]

Pinning virtual threads to only be scheduled on a particular OS thread greatly complicates the scheduling of them (when they are pinned due to monitors or native frames they prevent other virtual threads from running on that carrier, and this is normally a situation you want to avoid) and would raise a whole set of API questions around multiple virtual threads attempting to pin a platform thread local (do they block until it is unpinned from the current carrier thread, block until they are scheduled on a different carrier thread where the pinning attempt can be made again?). I would think there has to be a very good reason.to justify not using an object pool and a queue in this sort of situation.

Duncan.

From: loom-dev <loom-dev-retn at openjdk.org> on behalf of Glavo <zjx001202 at gmail.com>
Date: Tuesday, 1 November 2022 at 04:58
To: Volkan Yazıcı <volkan at yazi.ci>
Cc: loom-dev at openjdk.org <loom-dev at openjdk.org>
Subject: Re: Thread-local successor for object pooling
[External Email]

________________________________
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<mailto: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<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/0e0003f5/attachment-0001.htm>