Actors, Green Threads and CSP on the JVM • Hacker News Board

Re: Actors, Green Threads and CSP on the JVM

#31

Post by pron » Wed, Sep 03, 2014, 4:10 PM UTC

arielweisberg wrote: post #25

heavenlyhash wrote: post #16

I can't help but wonder if the article of the author has seen Quasar: http://docs.paralleluniverse.co/quasar/ It seems to be a concrete refutation of his claims of impossibility. Quasar successfully brings green threads to the jvm. It includes both channels as are now popularized by golang, as well as higher level patterns like actors. Despite the young nature of the framework, benchmarks show it comparing reasonably…

For me the caveat that calling a library or existing code can block the scheduler is a non-starter. I love what everyone is doing and I don't think it means they are useless, but for certain tasks and existing projects it means they are impractical to incorporate. I think it's fair to say that what we are being offered is not ponies. It's a useful tool, but also a leaky abstraction and not what I want to be working w…

Accidentally blocking the scheduler in Quasar is immediately detected and results in a warning with the exact stack trace of the offending operation. Also, that doesn't really "block the scheduler" but merely one of its threads. ForkJoin is more than capable dealing with occasional kernel threads blocking.

Re: Actors, Green Threads and CSP on the JVM

#32

Post by Blackthorn » Wed, Sep 03, 2014, 4:15 PM UTC

pron wrote: post #30

heavenlyhash wrote: post #16

I can't help but wonder if the article of the author has seen Quasar: http://docs.paralleluniverse.co/quasar/ It seems to be a concrete refutation of his claims of impossibility. Quasar successfully brings green threads to the jvm. It includes both channels as are now popularized by golang, as well as higher level patterns like actors. Despite the young nature of the framework, benchmarks show it comparing reasonably…

Author of Quasar here and apparently the target of the criticism in the article. It's kind of hard to make out the main claim the author has, but let me respond to the few more specific claims: 1. ForkJoin is not "notorious for its overhead". In fact, it is among the best implemented, best performing work stealing schedulers out there. Scheduling a task with ForkJoin takes a few nanos, and is almost as cheap as a pla…

While you're here, can I just thank you for Quasar/Pulsar? Amazing piece of engineering work, every language deserves a threading library like that.

Re: Actors, Green Threads and CSP on the JVM

#33

Post by jallmann » Wed, Sep 03, 2014, 4:21 PM UTC

jerven wrote: post #19

Wonder what the original author thinks of http://erjang.org/ or erlang on the jvm.

Erlang on the JVM as anything more than a toy is fundamentally misunderstanding Erlang -- which basically reinforces the article's central thesis. The article mentions the need for lightweight concurrency support to be baked into the platform -- the Erlang VM is the epitome of this. Idiomatic Erlang spawns a large number of isolated, concurrent processes, and lets them crash when things go wrong, with supervision trees to recover and restart processing. If a single JVM thread crashes, the whole VM goes. Additionally, you also lose secondary benefits such as per-process heaps/GC, etc. These things are impossible to cleanly graft on to the JVM.

Re: Actors, Green Threads and CSP on the JVM

#34

Post by arielweisberg » Wed, Sep 03, 2014, 4:33 PM UTC

pron wrote: post #31

arielweisberg wrote: post #25

Earlier quoted context omitted.

For me the caveat that calling a library or existing code can block the scheduler is a non-starter. I love what everyone is doing and I don't think it means they are useless, but for certain tasks and existing projects it means they are impractical to incorporate. I think it's fair to say that what we are being offered is not ponies. It's a useful tool, but also a leaky abstraction and not what I want to be working w…

Accidentally blocking the scheduler in Quasar is immediately detected and results in a warning with the exact stack trace of the offending operation. Also, that doesn't really "block the scheduler" but merely one of its threads. ForkJoin is more than capable dealing with occasional kernel threads blocking.

That's my point. I don't want a warning. I want it to just work ala Erlang. Injecting notifications to the threading framework that I might block is not ponies.

Out of curiousity how is Quasar detecting blocking?

To my knowledge ForkJoin doesn't detect blocking?

From the JDK 7 ForkJoin javadoc > However, no such adjustments are guaranteed in the face of blocked IO or other unmanaged synchronization

Sure the framework has extra threads and will work around it via work stealing, but you can get a lot of blocked threads at the worst possible time when you hit a correlated source of blocking.

You also lose thread affinity once work stealing kicks off.

Notifying a framework of potential blocking is certainly less nasty than what I do to work around blocking without one, but for an existing project of sufficient scope it's tough to transition.

Re: Actors, Green Threads and CSP on the JVM

#35

Post by mike_hearn » Wed, Sep 03, 2014, 4:36 PM UTC

jallmann wrote: post #33

jerven wrote: post #19

Wonder what the original author thinks of http://erjang.org/ or erlang on the jvm.

Erlang on the JVM as anything more than a toy is fundamentally misunderstanding Erlang -- which basically reinforces the article's central thesis. The article mentions the need for lightweight concurrency support to be baked into the platform -- the Erlang VM is the epitome of this. Idiomatic Erlang spawns a large number of isolated, concurrent processes, and lets them crash when things go wrong, with supervision tre…

Er, you can easily write a Java thread that just terminates or restarts itself if it crashes ...

Re: Actors, Green Threads and CSP on the JVM

#36

Post by pron » Wed, Sep 03, 2014, 4:42 PM UTC

arielweisberg wrote: post #34

pron wrote: post #31

Earlier quoted context omitted.

Accidentally blocking the scheduler in Quasar is immediately detected and results in a warning with the exact stack trace of the offending operation. Also, that doesn't really "block the scheduler" but merely one of its threads. ForkJoin is more than capable dealing with occasional kernel threads blocking.

That's my point. I don't want a warning. I want it to just work ala Erlang. Injecting notifications to the threading framework that I might block is not ponies. Out of curiousity how is Quasar detecting blocking? To my knowledge ForkJoin doesn't detect blocking? From the JDK 7 ForkJoin javadoc > However, no such adjustments are guaranteed in the face of blocked IO or other unmanaged synchronization Sure the framework…

AFAIK Erlang doesn't even warn you if you call blocking C code. The way Quasar does it is as follows: every time a fiber becomes runnable, it has a counter incremented. Every once in a while (I think 100ms) a special (kernel) thread goes over all FJ's worker threads and takes note of the fiber each is currently running and its counter (this requires some memory fences, but we take advantage of those already found in Quasar, so there's no added overhead). If it encounters the same fiber, with the same count twice, you've got a "runaway fiber", that's either blocking, or spinning too long. You can further examine the thread's state to see if it's blocked or not, to figure out which of the two things is happening.

Just to clarify: it's perfectly OK to call blocking code on Quasar fibers. In fact, it's encouraged. But the blocking call must be "fiber aware", and there's a project called Comsat, that takes many popular Java libraries and makes them fiber-blocking without changing their APIs.

This leads me to another point, which is time-slice based preemption of fibers. That's a feature Quasar had early in it's evolution, but has since been taken out (Quasar is preemptive, but doesn't offer time-slice scheduling). The reason is that time-slice scheduling is great when you have hundreds of threads running, but quite terrible when you have a million, because it means that the threads (lightweight or not) constantly compete for CPU cycles that the CPU just can't keep up with. In Java, plain threads are still available (with the same API as fibers, i.e. new Thread vs. new Fiber etc.), so for long-running computations, you're better off using a kernel thread; work-stealing scheduler aren't great at scheduling such tasks anyway. In Erlang, you don't have access to kernel threads, so time-slice scheduling is necessary to support the occasional heavy-computation process.

Re: Actors, Green Threads and CSP on the JVM

#37

Post by heavenlyhash » Wed, Sep 03, 2014, 4:44 PM UTC

arielweisberg wrote: post #25

heavenlyhash wrote: post #16

I can't help but wonder if the article of the author has seen Quasar: http://docs.paralleluniverse.co/quasar/ It seems to be a concrete refutation of his claims of impossibility. Quasar successfully brings green threads to the jvm. It includes both channels as are now popularized by golang, as well as higher level patterns like actors. Despite the young nature of the framework, benchmarks show it comparing reasonably…

For me the caveat that calling a library or existing code can block the scheduler is a non-starter. I love what everyone is doing and I don't think it means they are useless, but for certain tasks and existing projects it means they are impractical to incorporate. I think it's fair to say that what we are being offered is not ponies. It's a useful tool, but also a leaky abstraction and not what I want to be working w…

It's true that Erlang has some capabilities of preemption, but now we're getting into an altogether more interesting range of details.

Erlang is still essentially cooperative and not preemptive, if I've understood my reading. That means the BEAM VM is doing something very similar to the style of instrumentation Quasar is doing: it injects yields into your code at points it thinks are reasonable. This is not quite the same thing as true preemptive scheduling as OS-native threads do. Quasar could do this kind of safepoint injection as well, though afaik that's not currently a feature.

Your definition of ponies and mine seems to diverge here, and that's fine :) I agree that true preemptibility is an even higher bar we can hold scheduling frameworks to. But it's also a very complicated area to get into, it's not completely without it's tradeoffs (full preemptibility pretty much gets us back to OS native threads, right? and there's very real performance reasons there's so much momentum away from that right now), and I also feel that I can get a lot done with green threads without these features. Maybe we'll see a growing swing towards safepoint injection for psuedopreemptibility -- I'm just making words up at this point, as far as I know; if there's a better existing terminology for these shades of grey I'd love a link -- in the coming years. I don't know where I place my bets on that, yet.

EDIT: this also appears to have been discussed before at https://news.ycombinator.com/item?id=7962838

Re: Actors, Green Threads and CSP on the JVM

#38

Post by kylequest » Wed, Sep 03, 2014, 5:19 PM UTC

heavenlyhash wrote: post #16

I can't help but wonder if the article of the author has seen Quasar: http://docs.paralleluniverse.co/quasar/ It seems to be a concrete refutation of his claims of impossibility. Quasar successfully brings green threads to the jvm. It includes both channels as are now popularized by golang, as well as higher level patterns like actors. Despite the young nature of the framework, benchmarks show it comparing reasonably…

> I can't help but wonder if the article of the author has seen Quasar

Yes, given that the post links to Quasar code :-) Take a look at what the "bytecode weaving" link points to...

Re: Actors, Green Threads and CSP on the JVM

#39

Post by heavenlyhash » Wed, Sep 03, 2014, 5:34 PM UTC

pron wrote: post #30

heavenlyhash wrote: post #16

I can't help but wonder if the article of the author has seen Quasar: http://docs.paralleluniverse.co/quasar/ It seems to be a concrete refutation of his claims of impossibility. Quasar successfully brings green threads to the jvm. It includes both channels as are now popularized by golang, as well as higher level patterns like actors. Despite the young nature of the framework, benchmarks show it comparing reasonably…

Author of Quasar here and apparently the target of the criticism in the article. It's kind of hard to make out the main claim the author has, but let me respond to the few more specific claims: 1. ForkJoin is not "notorious for its overhead". In fact, it is among the best implemented, best performing work stealing schedulers out there. Scheduling a task with ForkJoin takes a few nanos, and is almost as cheap as a pla…

> That's exactly the purpose of the Comsat project, which integrates existing third-party libraries with Quasar fibers.

Indeed! :) And Comsat is a hugely important part of Quasar's growing usability in real-world applications. (I'm using the servlet & JAX-RS code right now. So yeah, it's safe to say I'm thrilled about those integrations.)

Quasar also has great abstractions available if one needs to generate new bindings to any code which can currently produce callbacks: FiberAsync [1] is every bit as simple to use as the docs indicate.

But it is still slightly-more-than-none work required when dealing with hollywood frameworks that haven't already been adapted. It's totally manageable; at the same time, it's my personal hope in the long run we see more frameworks growing up that deal with green threading naturally.

[1] http://docs.paralleluniverse.co/quasar/javadoc/co/parallelun...

Re: Actors, Green Threads and CSP on the JVM

#40

Post by derengel » Wed, Sep 03, 2014, 5:48 PM UTC

mateuszf wrote: post #7

Anyone using core.async knows how this article relates to it?

It applies equally, core.async is a CSP implementation on the JVM, it would be interesting to know how core.async relates to this issue on the browser instead of the JVM.