[External] : Re: jstack, profilers and other tools

[Alex Otenko]

Correct. But if you control how many connections you are reading, then you
control how much memory you spend on that. Hence reading 100 connections
10kb at a time won't pin more than 1mb. But if you don't have control over
how many connections you are reading from, which is the case with sync API,
then you might be pinning 100mb before one request becomes available.

On Sun, 24 Jul 2022, 16:52 Pedro Lamarão, <pedro.lamarao at prodist.com.br>
wrote:

> Em dom., 24 de jul. de 2022 às 10:08, Alex Otenko <
> oleksandr.otenko at gmail.com> escreveu:
>
>
>> Also, I am not clear why you dismissed the allocation problem by just
>> saying IO buffering is the same. The allocation problem is that user code
>> allocates before read(byte[]) is called. This is the same in both sync and
>> async code. The difference is that in async code the lifespan of the
>> allocation is shorter - we read only read-ready channels, and those that
>> aren't ready return quickly. In sync code the buffer remains allocated for
>> a long time - even seconds, if that's what the connection reuse pattern is
>> on the client side.
>>
>
> I am not what this allocation problem is supposed to be.
> If you have provisioned the memory required to support your workload,
> it doesn't matter for how long some buffer remains "inside" a call.
> If you have not provisioned the memory required to support your workload,
> then you have an architectural problem no matter how little time some
> buffer remains "inside" a call;
> you will crash when concurrent reads peak.
> Am I missing something?
>
> --
> Pedro Lamarão
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20220724/fee87204/attachment.htm>