Thread-local successor for object pooling

[Glavo]

Well, I didn't mean to pin the virtual thread to the platform thread. I
mean, the virtual thread tries to steal the value from the current platform
thread when calling the pin method.
After that, it can be freely switched to other platform threads, but still
has the value, and will not be returned to the platform thread until unpin.

However, after rethinking the problem, I feel that such a new abstraction
is really not needed.
We can combine ThreadLocal and ConcurrentLinkedQueue, continue to use
ThreadLocal for platform threads, and use ConcurrentLinkedQueue for virtual
threads for caching, which should be enough.


On Tue, Nov 1, 2022 at 7:15 PM Duncan MacGregor <
duncan.macgregor at servicenow.com> wrote:

> 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> 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/78e8516f/attachment.htm>