Jetty and Loom

[Ron Pressler]

P.S.

3. That reasoning would actually make more sense for StringBuilder (where it would
actually reduce allocation) than for virtual threads. I think we all agree that the merits of 
pooling StringBuilder are such that the idea should not be be put into the minds of 
Java programmers, and that the general advice would be to just not do it.

— Ron

On 5 January 2021 at 00:46:09, Ron Pressler (ron.pressler at oracle.com) wrote:

1. The stack is not always reused even for a single virtual thread: A complex interaction with 
the GC is at the core of the current implementation. So pooling virtual threads will not actually 
reuse the stack objects in the current implementation.

2. The assumption that allocation is always what places most pressure on GCs is not true in 
general, and with special objects like our stacks in particular. Having said that, I’m pretty sure 
that the implementation, including its elaborate interaction with the GC, will evolve further.

— Ron


On 5 January 2021 at 00:27:33, Mike Rettig (mike.rettig at gmail.com) wrote:

I cannot think of a good use for pooling virtual threads, and it seems to
me that any such use would be an anti-pattern with big downsides and no
upsides, but if anyone can think of a good reason to pool cheap objects,
please share.

 Virtual threads might need to be pooled to reuse the stacks. That's an easy solution to the heap pressure created by the frequent allocation of stacks to service tasks that require deep stacks.  

Mike


On Mon, Jan 4, 2021 at 1:45 PM Ron Pressler <ron.pressler at oracle.com> wrote:
 

On 4 January 2021 at 17:55:58, Greg Wilkins (gregw at webtide.com (mailto:gregw at webtide.com)) wrote:

> I'm just saying that there are other reasons for using them
> other than just because kernel threads are slow to start. In the right
> circumstance, a thread pool (or an executor that limits concurrent
> executions) is a good abstraction. My stress on them is in reaction to
> the "forget about thread pools" meme, which I think would be better as a
> little less shiny projectile sounding.


A thread pool is not “an executor that limits concurrency.” It is a pool of
threads, which, as a side-effect of threads representing concurrency,
also happens to limit concurrency. The purpose of any kind of pool is to
avoid the cost of creating and disposing of objects. If the objects are
created and disposed-of cheaply, as is the case with virtual threads,
they should not be pooled. Platform threads, however, because they are
expensive, should be.

If you wish to limit the concurrency of operations carried out on virtual
threads, you should use constructs aimed at limiting concurrency, such
as semaphores. They offer benefits over thread pools — e.g. different 
operations on the same set of threads can have different concurrency
limits — and they don’t suffer from the significant downsides of thread
pools, such as making interruption very complicated, and leaking context
from one task to another.

There might be some reasonable use-cases for an executor that limits 
concurrency without pooling the threads, though, and it should be easy
to implement, but I’m not sure it should be included in the core libraries.

I cannot think of a good use for pooling virtual threads, and it seems to
me that any such use would be an anti-pattern with big downsides and no
upsides, but if anyone can think of a good reason to pool cheap objects,
please share.


— Ron