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

Fri Jul 22 19:59:03 UTC 2022

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

From: loom-dev <loom-dev-retn at openjdk.org> On Behalf Of Ron Pressler
Sent: July 22, 2022 12:03 PM
To: Pedro Lamarão <pedro.lamarao at prodist.com.br>
Cc: Remi Forax <forax at univ-mlv.fr>; Daniel Hinojosa <dhinojosa at evolutionnext.com>; loom-dev at openjdk.org
Subject: Re: [External] : Re: Motivation to put Continuation, ContinuationScope, and Scope in jdk.internal.vm package

That’s correct, and if we build a public construct such as generators on top of Continuation, it will do precisely this kind of thread-confinement checking. However, the Continuation class itself cannot do it, because it is used by constructs that do move it from thread to thread (namely, virtual threads), and take great care to do it safely, cooperating with the compiler and making sure such transitions only occur inside methods that the compiler knows to treat specially. 

— Ron

On 22 Jul 2022, at 15:33, Pedro Lamarão <pedro.lamarao at prodist.com.br <mailto:pedro.lamarao at prodist.com.br> > wrote:

Em sex., 22 de jul. de 2022 às 09:51, Ron Pressler <ron.pressler at oracle.com <mailto:ron.pressler at oracle.com> > escreveu:

The main issue is that the Continuation class can be used in a way that would cause the current thread (i.e. Thread.currentThread()) to change mid-method. This would not only break a lot of Java code in very surprising ways, but also some assumptions made by the JIT compilers. Therefore, all safe constructs based on continuations must be confined to a single thread (or implement a thread, as done by virtual threads).

I have once experimented designing a Generator based on Continuation. 

Reading your comment above, I fear I may have misunderstood the requirements.

I'll try to re-state it, please correct me if I'm wrong.

A Continuation is initialized with a scope and a runnable.

At some point it will be run for the first time in a certain thread.

>From this point onwards, this Continuation must continue to run always in the same thread.

If the Continuation yields, then it must be restarted in the thread to which ii is "bound", never in some other thread.

Is that correct?

Let us consider a Generator class defined over a Continuation.

The user calls _generate_ for the first time,

which calls _run_ on the Continuation for the first time,

"binding" the Continuation to the user's thread.

The Continuation function produces the value, stores it, and yields;

_generate_ returns the stored value to the user.

Eventually the user is going to call _generate_ again,

which must _run_ the Continuation again.

The JVM assumes that _run_ is always run on the "thread" to which the Continuation was bound.

Wouldn't it be enough to constrain _generate_ to be run always on the same thread,

a restriction which could be guaranteed by an assert?

-- 

Pedro Lamarão

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