<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-CA link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='mso-fareast-language:EN-US'>Ooooh … “</span>cooperating with the compiler and making sure such transitions only occur inside methods that the compiler knows to treat specially.”<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I know there are no ‘language’ changes, but I did not imagine there would be any cooperation with the compiler?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Out of curiosity what does this look like, or can you refer us to some other discussions?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Is this just normal Java reflection, or something deeper and more intimate with the compiler?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Cheers, Eric<span style='mso-fareast-language:EN-US'><o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US>From:</span></b><span lang=EN-US> loom-dev <loom-dev-retn@openjdk.org> <b>On Behalf Of </b>Ron Pressler<br><b>Sent:</b> July 22, 2022 12:03 PM<br><b>To:</b> Pedro Lamarão <pedro.lamarao@prodist.com.br><br><b>Cc:</b> Remi Forax <forax@univ-mlv.fr>; Daniel Hinojosa <dhinojosa@evolutionnext.com>; loom-dev@openjdk.org<br><b>Subject:</b> Re: [External] : Re: Motivation to put Continuation, ContinuationScope, and Scope in jdk.internal.vm package<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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. <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>— Ron<o:p></o:p></p><div><p class=MsoNormal><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>On 22 Jul 2022, at 15:33, Pedro Lamarão <<a href="mailto:pedro.lamarao@prodist.com.br">pedro.lamarao@prodist.com.br</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal>Em sex., 22 de jul. de 2022 às 09:51, Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> escreveu:<o:p></o:p></p></div><div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div><p class=MsoNormal>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).<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I have once experimented designing a Generator based on Continuation. <o:p></o:p></p></div><div><p class=MsoNormal>Reading your comment above, I fear I may have misunderstood the requirements.<o:p></o:p></p></div><div><p class=MsoNormal>I'll try to re-state it, please correct me if I'm wrong.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>A Continuation is initialized with a scope and a runnable.<o:p></o:p></p></div><div><p class=MsoNormal>At some point it will be run for the first time in a certain thread.<o:p></o:p></p></div><div><p class=MsoNormal>From this point onwards, this Continuation must continue to run always in the same thread.<o:p></o:p></p></div><div><p class=MsoNormal>If the Continuation yields, then it must be restarted in the thread to which ii is "bound", never in some other thread.<o:p></o:p></p></div><div><p class=MsoNormal>Is that correct?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Let us consider a Generator class defined over a Continuation.<o:p></o:p></p></div><div><p class=MsoNormal>The user calls _generate_ for the first time,<o:p></o:p></p></div><div><p class=MsoNormal>which calls _run_ on the Continuation for the first time,<o:p></o:p></p></div><div><p class=MsoNormal>"binding" the Continuation to the user's thread.<o:p></o:p></p></div><div><p class=MsoNormal>The Continuation function produces the value, stores it, and yields;<o:p></o:p></p></div><div><p class=MsoNormal>_generate_ returns the stored value to the user.<o:p></o:p></p></div><div><p class=MsoNormal>Eventually the user is going to call _generate_ again,<o:p></o:p></p></div><div><p class=MsoNormal>which must _run_ the Continuation again.<o:p></o:p></p></div><div><p class=MsoNormal>The JVM assumes that _run_ is always run on the "thread" to which the Continuation was bound.<o:p></o:p></p></div><div><p class=MsoNormal>Wouldn't it be enough to constrain _generate_ to be run always on the same thread,<o:p></o:p></p></div><div><p class=MsoNormal>a restriction which could be guaranteed by an assert?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>-- <o:p></o:p></p><div><div><div><p class=MsoNormal>Pedro Lamarão<o:p></o:p></p></div></div></div></div></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>