java.lang.ThreadBuilders and java.lang.ThreadBuilders.newVirtualThread() are not public

Wed Aug 21 13:54:15 UTC 2024

Hi Robert,

You mean using normal threads? We tried that years ago, and performance was awful.

Best regards, / Met vriendelijke groet,

Rick Hendricksen
Specialist Software Engineering

From: robert engels <robaho at icloud.com>
Sent: Wednesday, 21 August 2024 13:42
To: Rick Hendricksen <Rick.Hendricksen at vanderlande.com>
Cc: Alan Bateman <Alan.Bateman at oracle.com>; loom-dev at openjdk.org; Dennis van den Berg <Dennis.van.den.Berg at vanderlande.com>
Subject: Re: java.lang.ThreadBuilders and java.lang.ThreadBuilders.newVirtualThread() are not public

To clarify, if you are guarding every possible blocking operation, you can easily implement your own continuations/scheduler with locks - you don’t need virtual threads.

On Aug 21, 2024, at 6:36 AM, robert engels <robaho at icloud.com<mailto:robaho at icloud.com>> wrote:

If you’re doing this, instead of setting a variable - why not use a semaphore per logical cpu then you can run as many simulations in parallel across as many logical cpus as desired.

On Aug 21, 2024, at 6:20 AM, Rick Hendricksen <Rick.Hendricksen at vanderlande.com<mailto:Rick.Hendricksen at vanderlande.com>> wrote:

Hi Alan,

The way we identify simulation related blocking operations is by setting a variable right before parking the thread. The scheduler then checks if that variable is null or not, and if null it was not a simulation related blocking operation and we wait until we get a simulation related blocking operation. We can get away with this because we know we are running on a single thread.

We agree that if the API would have a way to communicate the reason for parking the thread, that would be preferable to setting a variable before parking.

Best regards, / Met vriendelijke groet,

Rick Hendricksen
Specialist Software Engineering

From: Alan Bateman <alan.bateman at oracle.com<mailto:alan.bateman at oracle.com>>
Sent: Wednesday, 21 August 2024 11:17
To: Rick Hendricksen <Rick.Hendricksen at vanderlande.com<mailto:Rick.Hendricksen at vanderlande.com>>; loom-dev at openjdk.org<mailto:loom-dev at openjdk.org>
Cc: Dennis van den Berg <Dennis.van.den.Berg at vanderlande.com<mailto:Dennis.van.den.Berg at vanderlande.com>>
Subject: Re: java.lang.ThreadBuilders and java.lang.ThreadBuilders.newVirtualThread() are not public

Be aware: This email was created outside of Vanderlande. Be cautious of its contents and do not click any links or attachments unless you recognise the sender and know the content is safe.

On 21/08/2024 09:13, Rick Hendricksen wrote:
Hi Alan,

Thanks for taking the time to help us with this issue.

We see three problems with using the default scheduler with maxPoolSize:

  1.  Other virtual threads which are not directly related to the simulation would slow down the simulation
  2.  Running multiple simulations in parallel would not be possible
In that case, parallelism means several VMs, each running with maxPoolSize=1, rather than running several simulations in the same VM at the same time.

  1.  We need full control over which thread runs, and how to treat yield. If the thread is yielding because of a simulation-related blocking operation, we want to run the next thread. If it’s yielding due to IO, we don’t want to switch to another thread. If IO wait would result in a yield, that would be unpredictable, and would affect the result of our simulation.

It would be very helpful for us if custom schedulers would be exposed. Could you tell us more about the explorations you mentioned? And is it an option to take our use case into account there?

There are two explorations at this time. One is allowing the scheduler be selected at virtual Thread create time, like the prototype API on the builder that was in EA builds for a long time but didn't get any feedback. One of the use-cases for this is servers that want to use their own event loop thread as a carrier to avoid hand-off. The other exploration is exposing a way to replace the system-wide scheduler for servers that want to manage their own thread pool rather than use a work stealing scheduler. We talked about this a bit at JVMLS 2024, I think the recordings will be posted soon.

Note that the problem space and the possible interface for custom schedulers is larger than might initially seem. You touched on exposing the "reason" for preemption and that is one of several things that a scheduler may need to be notified of. One thing that would be useful to know from your experiments is how you distinguish between your "simulation-related blocking operation" and the dozens of other possible cases where a thread may be preempted.

In any case, the summary on this topic is that it is being explored again but proceeding with great caution.

-Alan
________________________________

** Disclaimer **

This e-mail, including any attachments, may include proprietary and confidential information of Vanderlande and may only be read by the person or those persons to whom it is addressed.
This document is forwarded to you in such a form (e-mail) that Vanderlande cannot guarantee the completeness and/or correctness of its contents and information.
If you have received this e-mail message in error, please notify us immediately.
Please also delete this document from your computer.
This document may not be reproduced, copied, distributed, published, modified, or furnished to third parties, without the prior written consent of Vanderlande.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240821/f8fc2b5c/attachment-0001.htm>