Motivation to put Continuation, ContinuationScope, and Scope in jdk.internal.vm package

Pedro Lamarão pedro.lamarao at prodist.com.br
Fri Jul 22 14:33:25 UTC 2022


Em sex., 22 de jul. de 2022 às 09:51, Ron Pressler <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/5641a83a/attachment.htm>


More information about the loom-dev mailing list