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

[Ron Pressler]

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<mailto: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<mailto: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<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/20220723/45f261b5/attachment-0001.htm>