Loom compatibility?

[chrisseaton]

Can someone comment on Loom compatibility, please? Has it been tried recently? @aardvark179

[aardvark179]

So we originally did a very rough prototype of using Loom in TruffleRuby using low level continuations, and although this works for simple cases it would require a lot of work to resolve all the assumptions about threads in TruffleRuby and Truffle itself, and it is not clear that raw continuations will be publicly exposed in the final version of Loom.

So, a better way to approach this is to create virtual threads for fibers rather than OS level threads, and continue to use a thread executor for our fibres. The current problem with this approach for running any substantial code is that Truffle uses a subclass of java.lang.Thread to hold the context, and virtual threads are not subclassable (they are created via ThreadBuilders, either directly or through asking the builder for a factory). The only real reason for the subclassing of java.lang.Thread in Truffle is to hold the current context, and this can likely be done with scoped variables in Loom.

There is a also an issue around Truffle compilation and Loom. Truffle allows for the reification of scalar replaced objects in parent stack frames, and this is not yet handled by Loom's freezing and thawing code.

[eregon]

Using virtual threads seems suboptimal though, as we'd have 2 extra level of scheduling (virtual threads scheduling and the message queue to actually switch only when the Ruby code does it), when there is no need and scheduling is explicit for Ruby Fibers.

Virtual threads could allow automatic switching on blocking Java IO, but I doubt that would correspond to where Ruby Fibers should switch with a Thread#scheduler (and also they should not switch without a scheduler), so in practice I don't think that automatic scheduling would be compatible for Ruby.

it would require a lot of work to resolve all the assumptions about threads in TruffleRuby and Truffle itself

I think that wouldn't be so hard. We'd have to move a few ThreadLocal we use as Fiber-local to either the Ruby Fiber object or some FiberLocal. I expect in Truffle almost no changes would be needed, i.e., we would just happen to run different stacks on the same java.lang.Thread.

Mozart-Graal can interchangeably use Thread and native coroutines and it wasn't hard once there is a layer to abstract it. We might want such a layer in Truffle.

it is not clear that raw continuations will be publicly exposed in the final version of Loom

Can we clarify with the Loom team this would prevent language implementations to use the correct level of abstraction for existing concurrency primitives such as Ruby Fibers and so this API needs to be accessible? And working around would be a large performance cost?

[aardvark179]

So @eregon and I talked about this over Zoom. Virtual threads offer a useful amount of compatibility with existing Java libraries compared to raw continuations, and shouldn't impose much overhead. I'll produce a small example outside TruffleRuby to show how we can use a custom scheduler for things like fibres without the overhead of using queues.

Within the Loom project we'll keep an eye on performance and try to ensure that we keep the overhead of virtual threads to a minimum.

[eregon]

This is a well-detailed update of the status of Project Loom: http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html