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

[Ron Pressler]

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<mailto: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<mailto:ron.pressler at oracle.com>> wrote:


On 19 Jul 2022, at 18:38, Alex Otenko <oleksandr.otenko at gmail.com<mailto: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/20220721/93dfa400/attachment-0001.htm>