Graal: Coroutines support?

[yrsh]

Is it expected to support green threads or coroutines?

[arthurp]

I think it will be a while, but I also hope we eventually get them. The challenge is that the JVM itself doesn't support green thread/coroutines/fibers and graal cannot add them without support since Graal still uses the JVMs support for managing stacks and heap (and rewriting stacks during deopt and OSR).

@eregon's work Mozart-Graal uses a modified JVM 8 which supports coroutines. This work on JVM coroutines was part of MLVM back when that was a thing, but I don't think it ever even became a JSR and died at the prototype stage. I was kinda bummed. I think it would have been great to have it in unmodified JVMs. For more details on this and related stuff I recommend https://github.com/oracle/truffleruby/issues/106 which discusses this issue in the context of Ruby.

One thing to note though is that you could implement coroutines for a Graal/Truffle language. The restriction would be that you could only suspend the parts of the stack that are in YOUR language, so it wouldn't work with all the GraalVM interop stuff. However, the performance overhead could be pretty limited since you would only need to compile in the coroutine support in functions which actually suspend, mostly avoiding the overhead in non-suspending cases. My language (Orc) uses selective continuation-passing style to implement what are basically coroutines (though in my case I only use them to schedule concurrent tasks).

[jbduncan]

I think it's worth noting that Project Loom, an existing OpenJDK sub-project, is looking into implementing fibers and delimited continuations, both of which I understand are related to coroutines.

[yrsh]

@arthurp thank you for your response!
@jbduncan I've heard about loom, but seems that it is suspended. Has anyone already tried to use it in production?

[jbduncan]

@yrsh I admit I don't know if anyone uses Loom in production yet. I'd be surprised if that were the case, as I don't think it's come that far yet.

And yeah, I can see what you mean by how it seems suspended. I don't know why there's been a lack of activity recently.

I understand that @pron is or was working on Project Loom... :)

[jbduncan]

@yrsh Looks like Loom has seen some more activity just now. In fact, looks like a public prototype is available now!

[pron]

Yes. We've been working with the Graal team to add Graal support, which you can try right now (although not in SubstrateVM as of yet).

[eregon]

https://medium.com/graalvm/bringing-fibers-to-truffleruby-1b5d2e258953 by @chrisseaton shows some promising results for using Loom's Continuation in TruffleRuby.

[FroMage]

@pron any estimate as to when Loom will land on SVM?

[doctorpangloss]

As an aside, trying native-image on code AOT-instrumented with puniverse/quasar with 19.3.0.2-jdk11 produces a Error: Exception handler can be reached by both normal and exceptional control flow

@pron I will probably use uninstrumented variants as the near-term solution for my use case, a serverless function.

[chrisseaton]

Error: Exception handler can be reached by both normal and exceptional control flow

Do you think that's a Native Image error? Is it compliant bytecode that Native Image isn't anticipating because it isn't emitted by the Java or Scala compilers?

[doctorpangloss]

@chrisseaton how about I make a minimum test case?

I believe it is the same error as this: https://github.com/quarkusio/quarkus/issues/1957#issuecomment-481310575

Which uses the same instrumenting code, just under a different package name / fork.

[chrisseaton]

Yes seems relevant - someone just needs to pass it up to the SVM team with a minimum test case. It can probably be bytecode post-instrumentation if that makes the setup easier.

[doctorpangloss]

@chrisseaton I haven't forgotten about this I hope to get to a repro by the start of next week.

I will have most trouble setting up the test.

[doctorpangloss]

I never got around to this because I could never get Graal building on my macOS machine. I needed a guide!

Otherwise, can I just provide a Graal-built fat JAR that contains bytecode that fails instrumentation versus the same, uninsturmented version of that JAR that works? That I can definitely do.

[doctorpangloss]

See #2546 @chrisseaton