[reggieband]

> When code running in a virtual thread calls a blocking I/O operation in the java.* API, the runtime performs a non-blocking OS call and automatically suspends the virtual thread until it can be resumed later.

How does it know that an operation is blocking on I/O? Is this limited to stuff baked into the language or standard library?

What is the mechanism of suspension and resumption? They mention elsewhere that any platform thread could pick up any virtual thread so I assume they must be storing the stack somewhere. Is there a cost transferring stacks on virtual threads across platform threads? Does this introduce new security implications if there are less OS level restrictions on memory access between platform threads?

What happens in cases where an application has user defined platform threads? How does the system determine what platform threads are available to the virtual threading system?

I think this is probably the right decision for Java and I agree with all of their motivations. I personally like the explicitness of async/await, however I assume Java devs are very familiar with threading in general. I believe this allows an easier path to migrating existing Java code.

[jeremyjh]

> How does it know that an operation is blocking on I/O? Is this limited to stuff baked into the language or standard library?

Most libraries use the I/O primitives from the platform standard libraries, so the behaviour is going to trickle out from there. If you aren't using those libraries, the only other way to do I/O would be to use native code such as via JNI, and the runtime would schedule that on a thread pool and so it would tie up an OS thread for the duration of a function invocation.

[zmmmmm]

thanks, this explains the mysterious magic that I think is probably bugging a lot of people.

It will be interesting to see how much of a coloring problem this creates, if any. I guess the great thing about having it be standardised and baked into the language / VM is it will quickly become de facto best practice to make any such library code compliant with virtual threads. And for all its various downsides, the java ecosystem has always leaned away from native code and treated it as a last resort rather than leaning into it like Python etc. So likely it will not be a huge issue the way the coloring problem is in the async/await situation.

[samus]

As a preparation, some parts of the standard library indeed had to be rewritten in pure Java to be compatible with Loom, for example the socket implementations.

https://openjdk.java.net/jeps/373

http://openjdk.java.net/jeps/353

[jeremyjh]

Yes in other languages with this baked into the platform - such as Haskell, Go and Erlang - it just works and there is no color problem.

[kevincox]

> Is there a cost transferring stacks on virtual threads across platform threads?

You shouldn't need to "transfer" the stack. There isn't really a "platform stack", that is just whatever your stack pointer is pointing at. So it is perfectly fine to allocate many stacks and switch between them within one OS thread just by changing the stack pointer.

Of course if you are allocating a "full stack" then the main question is what is the point? IIUC the biggest cost of threads is the memory allocated to the stack. So unless you are doing something clever you don't get much benefit. There are many approaches here but I guess it is up to the runtime to pick one.

[aardvark179]

The largest cost is that you are allocating a fixed size stack, and that usually has to be big enough for whatever thread you might run. Virtual threads only have a stack as big as they require, and that’s likely to be fairly small. A lot of thought went into the foot print of virtual threads, we had long discussions about individual fields!

[aardvark179]

> What is the mechanism of suspension and resumption? They mention elsewhere that any platform thread could pick up any virtual thread so I assume they must be storing the stack somewhere.

Virtual threads are built on top of underlying delimited one shot continuations, and those store the stack. A large part of the engineering effort has been in making this as efficient as possible.

> Is there a cost transferring stacks on virtual threads across platform threads?

A stack always has to be at least partially copied to the carrier thread’s stack, and it doesn’t really matter which OS thread that is. I say partially because initially only the current stack frame will be copied as most threads will have a deep stack compared to the number of frames active in any operation likely to yield.

> Does this introduce new security implications if there are less OS level restrictions on memory access between platform threads?

The security model remains intact. A virtual thread performing some privileged operation will be privileged no matter which OS thread it is run on, and one which is not privileged will not be no matter the OS thread it runs on.

> What happens in cases where an application has user defined platform threads? How does the system determine what platform threads are available to the virtual threading system?

Virtual threads don’t just run on a random OS level thread. They run on a scheduler (commonly a fork join pool) and are effectively a series of tasks fed to that scheduler.

[samus]

When the security manager is removed, the issue of privileged threads will become moot.

[ackfoobar]

> How does it know that an operation is blocking on I/O?

https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1....

"All Your Blocking Are Belong to Us"

Not sure how updated the document is. But the section title says it all. (It's a reference to a meme.)