Jetty and Loom

[Mike Rettig]

>
> 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
>