Why Continuations Are Coming to Java • Hacker News Board

Re: Why Continuations Are Coming to Java

#71

Post by aardvark179 » Tue, Jul 02, 2019, 11:06 AM UTC

trias wrote: post #65

Honest question, maybe obvious: Why is the java-scheduler/ thread model so much better than the OS-level one? What does the java one do, or better what does it not do? And why can't the principles which make java-scheduling fast be applied to OS-threads?

There's a few different things to unpack in that question.

1. Fibers are more lightweight than threads because we only need to carry around a small amount of state representing the stack used so far by the fiber and a few other things. So it should be possible to have many more of them than we can have OS threads.

2. We can in theory make decisions about scheduling based on what the program is doing in ways that the OS cannot do. For example if one fiber releases a lock we might know to schedule the fiber waiting for that lock in preference to anything else, and would not have to wake all fibers waiting on that lock and let them race to acquire it as commonly happens with OS threads.

3. Some of these advantages can be done with OS threads when combined with user scheduling. This is available in Windows, but has not made it into mainline Linux yet. It allows the application to give the OS useful hints on which thread to schedule next, but it doesn't really reduce the weight of the threads themselves.

(I work for Oracle, and spend some of my time on project loom. These opinions are my own.)

Re: Why Continuations Are Coming to Java

#72

Post by agumonkey » Tue, Jul 02, 2019, 11:10 AM UTC

anybody get this feeling that all languages are converging to a similar core set ?

Re: Why Continuations Are Coming to Java

#73

Post by aardvark179 » Tue, Jul 02, 2019, 11:10 AM UTC

dancek wrote: post #36

We had a weird network issue in a production system, and because the interplay of different components was very difficult to debug I briefly investigated each component. This lead me to run Jersey (a JAX-RS implementation, ie. a REST library) with a debugger. Jersey is written in a continuation passing style. That's the only time I've seen the style outside academic discussions of Scheme. I found the code flow diffic…

We're using the underlying continuations in Loom to build fibers. You don't need to pass continuations, you just write normal blocking code and the runtime takes care of yielding and scheduling. All you have to do is run things as fibers, which is pretty much like running them as threads.

Re: Why Continuations Are Coming to Java

#74

Post by aardvark179 » Tue, Jul 02, 2019, 11:12 AM UTC

SeanLuke wrote: post #28

How does this differ from scheme-style continuations? IIRC, full continuations in the scheme sense of the term are currently impossible in Java as they require forbidden stack manipulation. Or is what's being proposed here something entirely else?

We're adding delimited one-shot continuations to the JVM. The common public interface to these is likely to be fibers rather than raw continuations, as they are much easier to work with and allow the standard library and lots of existing code to take advantage of the new features with little to no change.

Re: Why Continuations Are Coming to Java

#75

Post by trias » Tue, Jul 02, 2019, 11:16 AM UTC

tpxl wrote: post #66

trias wrote: post #65

Honest question, maybe obvious: Why is the java-scheduler/ thread model so much better than the OS-level one? What does the java one do, or better what does it not do? And why can't the principles which make java-scheduling fast be applied to OS-threads?

The lightweight threads(fibers) are actually not threads on the OS level, they just behave similarly. As such there are no context switches etc., which are slow.

i know, but why doesn't the OS do this too? Most programmers don't care if their "thread" is an actual thread on the machine or just a "fiber". If the benefits are this large, it should be provided by the OS in my opinion.

Re: Why Continuations Are Coming to Java

#76

Post by drcode » Tue, Jul 02, 2019, 11:17 AM UTC

agumonkey wrote: post #72

anybody get this feeling that all languages are converging to a similar core set ?

All languages are becoming Lisp, except for the added challenge of avoiding parentheses.

Re: Why Continuations Are Coming to Java

#77

Post by pron » Tue, Jul 02, 2019, 11:19 AM UTC

avodonosov wrote: post #59

The question is not why, but when. When? Our server has long waiting http handlers, which occupy java threads while waiting, thus limiting the server throughput to the number of threads java can maintain, and I'm holding off a rewrite on async servlets for several years already to avoid complicating the code, because I hope cheap threads (fibers) will become available, but there is no timeline for Loom. When can we h…

As OpenJDK has switched to time-based releases, we no longer plan releases based on features. When a feature is ready, it is merged into the mainline and released in the following release. We never commit to a timeline, but I would say that the probability for fibers to land in one of the two releases next year as quite high. Of course, we release projects gradually, and it's possible that some planned fiber features will not land in the first release, or that the performance in the first release will later be improved etc.

However, early access Loom binaries (with API still very much in flux) are expected in a month or so, with the intention of gathering feedback on the API. The decision on when fibers are ready to be merged will greatly depend on that feedback.

Re: Why Continuations Are Coming to Java

#78

Post by TickleSteve » Tue, Jul 02, 2019, 11:24 AM UTC

aardvark179 wrote: post #71

trias wrote: post #65

Honest question, maybe obvious: Why is the java-scheduler/ thread model so much better than the OS-level one? What does the java one do, or better what does it not do? And why can't the principles which make java-scheduling fast be applied to OS-threads?

There's a few different things to unpack in that question. 1. Fibers are more lightweight than threads because we only need to carry around a small amount of state representing the stack used so far by the fiber and a few other things. So it should be possible to have many more of them than we can have OS threads. 2. We can in theory make decisions about scheduling based on what the program is doing in ways that the…

Regarding point 2)

That is not how OS level threads would work. When a lock is released, the next ready-to-run task (blocked on that lock) will be made runnable. They wont all be released then 'race' to acquire the lock. The behaviour is identical in user-space or kernel-space.

Re: Why Continuations Are Coming to Java

#79

Post by TickleSteve » Tue, Jul 02, 2019, 11:31 AM UTC

trias wrote: post #75

tpxl wrote: post #66

Earlier quoted context omitted.

The lightweight threads(fibers) are actually not threads on the OS level, they just behave similarly. As such there are no context switches etc., which are slow.

i know, but why doesn't the OS do this too? Most programmers don't care if their "thread" is an actual thread on the machine or just a "fiber". If the benefits are this large, it should be provided by the OS in my opinion.

If the OS were to do it, it would involve a switch to kernel-space and would then be termed an OS-level thread...

Another way of putting it is that yes, Operating Systems do do it. Thats what an OS-level thread is.

Re: Why Continuations Are Coming to Java

#80

Post by kasperni » Tue, Jul 02, 2019, 11:34 AM UTC

oblio wrote: post #57

ScottBurson wrote: post #52

Ron Pressler!? Isn't that our very own 'pron'?

You should see him go on /r/java! I'm kidding, his posts are awesome :)

> You should see him go on /r/java!

Yeah, if just someone had banned him, we could have had Loom by now.

Just kidding as well... great work pron