Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coroutines support? #477

Closed
yrsh opened this issue Jun 16, 2018 · 16 comments
Closed

Coroutines support? #477

yrsh opened this issue Jun 16, 2018 · 16 comments
Assignees

Comments

@yrsh
Copy link

yrsh commented Jun 16, 2018

Is it expected to support green threads or coroutines?

@arthurp
Copy link

arthurp commented Jun 20, 2018

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 oracle/truffleruby#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
Copy link

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
Copy link
Author

yrsh commented Jul 19, 2018

@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
Copy link

@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
Copy link

jbduncan commented Jul 27, 2018

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

@pron
Copy link
Member

pron commented Jul 27, 2018

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
Copy link
Member

eregon commented Aug 1, 2018

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

@eregon eregon added the truffle label Aug 1, 2018
@FroMage
Copy link

FroMage commented Sep 5, 2018

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

@doctorpangloss
Copy link

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
Copy link
Contributor

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
Copy link

@chrisseaton how about I make a minimum test case?

I believe it is the same error as this: quarkusio/quarkus#1957 (comment)

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

@chrisseaton
Copy link
Contributor

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
Copy link

@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
Copy link

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
Copy link

See #2546 @chrisseaton

@spavlusieva
Copy link
Member

hi @yrsh , this issue has been inactive for more than 180 days. We’ll close it to focus on current issues. In case it’s still relevant, please reopen it and we’ll take another look. Thank you!

@spavlusieva spavlusieva closed this as not planned Won't fix, can't repro, duplicate, stale Nov 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests