loom ea based jdk18 feedback

[Remi Forax]

----- Original Message -----
> From: "Øystein Myhre Andersen" <o.myhre at gmail.com>
> To: "Ron Pressler" <ron.pressler at oracle.com>
> Cc: "dreamlike_ocean lei" <dreamlike.vertx at gmail.com>, "loom-dev" <loom-dev at openjdk.java.net>
> Sent: Mercredi 17 Novembre 2021 16:51:18
> Subject: Re: loom ea based jdk18 feedback

> The Continuation API in a single thread is exactly what I want in my
> implementation of Simula's Quasi Parallel Systems.
> I have used it in an experimental implementation and it works well.
> The performance of great simulation models is excellent.
> 
> - Øystein

You can implement an API similar to the Continuation API on top of the virtual thread API.
The only guarantee that you are loosing is that the platform thread can be different each time you call run().

The continuation can jump to another platform thread but given that the thread that run the continuation and the continuation can not run at the same time, the code can be thread-safe
(you also have to not botch the memory effects when you switch back and forth, i hope my code is correct on that point).

Obviously, it's heavier and if you have things like ThreadLocal in the mix, it will not work well, but if you start the thread that control the Continuation and the virtual thread on the same executor, it should not be too bad.

regards,
Rémi

[1] https://github.com/forax/loom-fiber/blob/master/src/main/java/fr/umlv/loom/continuation/Continuation.java

> 
> On Wed, Nov 17, 2021 at 4:38 PM Ron Pressler <ron.pressler at oracle.com>
> wrote:
> 
>>
>>
>> > On 17 Nov 2021, at 11:13, dreamlike_ocean lei <dreamlike.vertx at gmail.com>
>> wrote:
>> >
>> > 1, continuation api
>> >
>> >
>> > I really hope I can directly access this api in the future version
>>
>> The Continuation class is fundamentally unsafe, and using it might result
>> in miscompilation, as the JIT compiler bases some optimisations on the
>> assumption that the current thread cannot change. So there is currently no
>> way of exposing this particular class (which is mostly of interest for
>> research). However, in the future, the JDK could conceivably add safe
>> abstractions built on top of Continuation other than virtual threads, that
>> would probably be confined to a single thread. Custom schedulers will be
>> able to give you what I believe you want.
>>
>> >
>> >   Virtual thread custom scheduler
>> >
>> >
>> > I hope you can consider reopening the api of the custom scheduler in the
>> > future version
>>
>> That is an API we would very much like to have, but we haven’t had time to
>> review yet. I don’t know yet whether or not it will make it in time for the
>> first release. Note that this is a very specialised API for internal,
>> sophisticated, use by frameworks, only, and should rarely if ever be used
>> by user code. Naturally, we prioritise the user-facing APIs.
>>
>>
>> — Ron
>>
>>
>>