Jetty and Loom

[Mike Rettig]

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

I see StringBuilder reused frequently. It usually isn't pooled, but if you
know you are going to be constructing large strings then it makes sense to
reuse a StringBuilder (maybe even stash it in a ThreadLocal if you're
lazy).  For tiny strings it probably won't matter, but just like deep
stacks, strings can be quite large.

Mike

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

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