[External] : Re: Motivation to put Continuation, ContinuationScope, and Scope in jdk.internal.vm package

Ron Pressler ron.pressler at oracle.com
Fri Jul 22 22:57:55 UTC 2022



On 22 Jul 2022, at 20:59, eric at kolotyluk.net<mailto:eric at kolotyluk.net> wrote:

Ooooh … “cooperating with the compiler and making sure such transitions only occur inside methods that the compiler knows to treat specially.”

I know there are no ‘language’ changes, but I did not imagine there would be any cooperation with the compiler?

Out of curiosity what does this look like, or can you refer us to some other discussions?

Is this just normal Java reflection, or something deeper and more intimate with the compiler?

Cheers, Eric

I meant the JIT compiler(s). Look here: https://github.com/openjdk/jdk/blob/987656d69065b5b61d658cec3704a181a4aef18b/src/java.base/share/classes/java/lang/VirtualThread.java#L270

The special @ChangesCurrentThread annotation on that method and a couple of others tells the compiler (i.e. the JIT compiler) to turn off some optimisations that rely on the assumption that the current thread cannot change in the middle of a method.

Neglecting that annotation could rely in miscompilation and very strange bugs, and we can’t statically infer that property, so that is why the Continuation class is not safe when used directly. Virtual threads take care to interact with the compiler in this way, but other constructs based on continuations must be thread-confined to be safe.

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


More information about the loom-dev mailing list