: Re: Project Loom VirtualThreads hang

[Arnaud Masson]

Ron,

My concern is that Loom (in its current form) greatly improves scalability on IO-bound requests and but introduce a new fairness problem regarding CPU-bound request.

Of course generally on web apps, most requests are IO-bound (http, jdbc) but I do have seen CPU-bound requests on prod (sometimes accidental).

I don’t use Loom on prod today (I guess not a lot of people do since it’s still preview), so if you are asking if I see a production issue, answer is no.

I suppose if I want to migrate to loom and be safe, I can increase the number of native carriers in the underlying pool (N >> core count).
It’s just that if there was timesharing in Loom, I don’t see why vthreads would not be systematically used (almost blindly, for CPU-bound and IO-bound).

I’m curious, when do you think preemptive time sharing (as implemented in various OSes for decades) is useful?

thanks
Arnaud


What you’re showing is not a problem. It’s a scenario that you hypothesise could be a problem, and then you further hypothesise that a certain mechanism would fix the hypothetical problem. But we can’t fix something until we see an actual problem and know what it is that requires fixing.

In particular, I don’t know why you have to be preemptively concerned about a problem you have not seen, and that platform threads aren’t known to address either. In fact, virtual threads already give you better fairness than both platform thread pools and async code. So are you concerned that virtual threads will improve things but not to the extent you wish there was something that could?

— Ron

Unless otherwise stated above:

Compagnie IBM France
Siège Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 664 069 390,60 €
SIRET : 552 118 465 03644 - Code NAF 6203Z
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230106/9187bf29/attachment.htm>