Future.get() performance

[Alan Bateman]

On 28/04/2022 21:05, August Nagro wrote:
> Hello,
>
> It's very exciting to see that Loom is going into preview.. thank you for
> the hard work.
>
> I noticed in the JEP page that this example of interoperability with
> Futures was given:
>
> response.send(future1.get() + future2.get());
>
> Have there been any thoughts about improving the performance of .get()
> under loom?
>
> My understanding is that the method is implemented by submitting a
> ManagedBlocker to the fork join pool, which polls the future every X
> milliseconds until it's completed.
>
> I would think that instead, you could have some special logic if the thread
> is virtual.
>
> It would directly suspend the continuation, and add a callback to the
> future. When the future completes, the callback is executed, allowing the
> continuation to be resumed.
A platform thread calling Future::get works exactly as before. If the 
computation hasn't completed then thread will park/wait as before.

A virtual thread calling Future::get may park and release the underlying 
carrier to do other work. Maybe in some extreme case you end up with 
hundreds of thousands of virtual threads blocked in Future::get, that 
should work just fine.

So I think what are looking for is already there. There are early access 
builds to try it yourself if you want.

-Alan