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

[Alex Otenko]

I think none of this statement has anything to do with Little's law.

On Sat, 23 Jul 2022, 02:04 Ron Pressler, <ron.pressler at oracle.com> wrote:

> We’re talking about thread-per-request programs. In such programs, one
> thread has a concurrency of one (i.e. it handles one request, hence
> “thread-per-request”). As I explained, to get higher concurrency than
> what’s allowed by the number of OS threads you can *either* use user-mode
> threads *or* not represent a unit of concurrency as a thread, but here
> we’re talking about the former. All that is covered in JEP 425.
>
> — Ron
>
> On 23 Jul 2022, at 00:25, Alex Otenko <oleksandr.otenko at gmail.com> wrote:
>
> I think the single threaded example I gave speaks for itself. 1 thread can
> sustain various throughputs with various concurrency. I've shown a case
> with 99 concurrent requests, as per Little's law (and I agree with it),
> and it's easy to see how to get any higher concurrency.
>
> There are other laws at play, too, so my example latency wasn't random.
> But this has been long enough.
>
>
> On Thu, 21 Jul 2022, 12:30 Ron Pressler, <ron.pressler at oracle.com> wrote:
>
>> Little’s law has no notion of threads, only of “requests.” But if you’re
>> talking about a *thread-per-request* program, as I made explicitly clear,
>> then the number of threads is equal to or greater than the number of
>> requests.
>>
>> And yes, if the *maximum* thread count is low, a thread-per-request
>> program will have a low bound on the number of concurrent requests, and
>> hence, by Little’s law, on throughput.
>>
>> — Ron
>>
>> On 20 Jul 2022, at 19:24, Alex Otenko <oleksandr.otenko at gmail.com> wrote:
>>
>> To me that statement implies a few things:
>>
>> - that Little's law talks of thread count
>>
>> - that if thread count is low, can't have throughput advantage
>>
>>
>> Well, I don't feel like discussing my imperfect grasp of English.
>>
>> On Tue, 19 Jul 2022, 23:52 Ron Pressler, <ron.pressler at oracle.com> wrote:
>>
>>>
>>>
>>> On 19 Jul 2022, at 18:38, Alex Otenko <oleksandr.otenko at gmail.com>
>>> wrote:
>>>
>>> Agreed about the architectural advantages.
>>>
>>> The email that triggered my rant did contain the claim that using
>>> Virtual threads has the advantage of higher concurrency.
>>>
>>> > The throughput advantage to virtual threads comes from one aspect —
>>> their *number* — as explained by Little’s law.
>>>
>>>
>>>
>>>
>>> Yes, and that is correct. As I explained, a higher maximum number of
>>> threads does indeed mean it is possible to reach the higher concurrency
>>> needed for higher throughput, so virtual threads, by virtue of their
>>> number, do allow for higher throughput. That statement is completely
>>> accurate, and yet it means something very different from (the incorrect)
>>> “increasing the number of threads increases throughput”, which is how you
>>> misinterpreted the statement.
>>>
>>> This is similar to saying that AC allows people to live in areas with
>>> higher temperature, and that is a very different statement from saying that
>>> AC increases the temperature (althoughI guess it happens to also do that).
>>>
>>> — Ron
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20220724/efaca12a/attachment-0001.htm>