Jetty and Loom

[Alan Bateman]

On 05/01/2021 08:23, Greg Wilkins wrote:
> :
>
>       For now, Object.wait works with the FJP managedBlocker mechanism
>     to increase parallelism during the wait. So the pool 16 carrier
>     threads will increase when executing code where Object.wait is used.
>
>
> Ah that is interesting to know.  I had written a test 
> <https://urldefense.com/v3/__https://github.com/webtide/loom-trial/blob/main/src/main/java/org/webtide/loom/CPUBound.java__;!!GqivPVa7Brio!LPjNVnMCPREZki0_TULb6XQr27MxBeuHNQhjmUmusu_u3jVteqw8C3IftRIyx0BDYA$>  
> that confirmed virtual threads are deferred by CPU bound tasks, but I 
> had not checked synchronised.
User mode threads aren't intended for compute bound tasks so the 
observations with the test that consumes 1M tokens is correct. We have 
underlying support for forced preemption but TBD if anything will be 
ever be exposed to schedulers. The system is seriously under provisioned 
if there a million threads trying to execute compute bound tasks 
concurrently. We have prototyped watchdogs and other means to identify 
virtual threads that are mounted for an extended periods and that may be 
something that is part of the serviceability story.


>
> So Loom can spawn new kernel Theads if Object.wait is used!   What is 
> the limit of that?   In a pathological case of an application doing 
> lots of Object.waiting, could it eventually end up 1:1 kernel:virtual 
> threads?   If so, then I guess there is an issue of many spawned 
> virtual threads suddenly needing too many kernel threads?  I can't see 
> how either OOM or deadlock can be avoided generally?       Sure apps 
> can be rewritten, but Jetty is not in control of the applications 
> deployed on it.
As I said, the limitation with Java monitors is one that we expect will 
go away in the future. A lot of challenges and unknowns to work through. 
We don't consider it a blocker for an initial preview or first release, 
rather more of a quality-of-implementation issue. There is a diagnostic 
option to detect cases where parking pins the thread because it is 
holding a monitor. Also code migrating to virtual threads can use 
j.u.concurrent locks if excessive pinning is causing performance issues.

Yes, Object.wait does increase parallelism temporarily. Condition::await 
from code executing in a FJP does the same. As things stands, the 
default scheduler sets the max thread count to 128 but it is 
configurable (-Djdk.defaultScheduler.maxPoolSize=200 for example). Yes, 
deadlocks are possible if all threads are blocked in Object.wait, same 
thing is possible with fixed threads too of course.

-Alan