effectiveness of jdk.virtualThreadScheduler.maxPoolSize

[Ron Pressler]

On 9 Jan 2023, at 20:12, Arnaud Masson <arnaud.masson at fr.ibm.com<mailto:arnaud.masson at fr.ibm.com>> wrote:


On 9 Jan 2023, at 19: 02, Arnau
> We have not seen situations where virtual threads are the obvious choice and yet you see a problem

I suppose I see a problem where vthreads are not a so obvious choice 😊
It’s the main issue for Loom in its current form: to know in advance for each request if it’s Loom friendly (most requests I guess) or not.
More work for app devs.

No, I don’t think so. You’ve hypothesised that different resource consumption could lead to issues, but it’s not at all clear that it does in the real world. So if you find a case where this is a problem, report it. You’ve gone through an entire series of logical steps, and, having spent years on this, I tried explaining to you why it’s not clear that each step follows from the previous: It is not clear that different resource consumption causes any issue whatsoever in real workloads, and it’s not clear that if it does, time sharing is the solution. But since you have concerns, I suggest you wait and see what other report.


>Time-sharing doesn’t “scale gracefully”. It decreases the latency for some tasks at the cost of increasing it for others (and sometimes increasing the average), while having no impact on scalability (scheduling cannot affect scalability).

It is more graceful since it’s proportional to tasks own durations, instead of brutal pause at some threshold.

It has no impact on throughput or on server scalability, and it actually increases the maximum latency. I think you might be speculating over the effects of time sharing on server workloads rather than actually observing them.


Sorry, I don’t understand what you mean by reporting a problem, I thought that what I was doing here. You mean filling formal ticket?
(I can’t really run Loom on prod right now since it’s still JDK Preview.)


Production is, of course, more interesting, but it’s not at all a prerequisite for a report of an actual problem. What you’ve done so far is speculate that you may run into a problem (and the problem with your simulation, aside from it not simulating a server with an infinite stream of requests, is that it does not explain how the server keeps the long tasks at just the right rate). If you build a server based on virtual threads that you use to evaluate virtual threads for your production workloads by mimicking them as well as you can, and *then* run into a problem in testing, reporting that here would be useful, and have to potential of providing us with some new information.

— Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230109/1bb2e17b/attachment.htm>