Why Continuations Are Coming to Java

Application threads are a part of the application runtime environment. Thread scheduling is little more than a function call and doesn't involve a syscall invocation, and can be hooked into runtime environment trigger mechanisms.

Kernels have to be one size fits all, application threads can be tuned more precisely, with greater visibility over the application's state.

In the case of managing the stack, the kernel must be able to support languages like C/C++ and Rust, that can have internal pointers pointing into the stack itself. This makes it hard to reallocate stacks dynamically and move them around in memory. The JVM doesn't allow such pointers in application code, and internal bookkeeping pointers are known.

As to the scheduler, the kernel must support very different kinds of threads: threads that serve server transactions that block very often, and threads that, say, encode a video, that rarely block at all. These different kinds of threads are best served by different schedulers (e.g. the "frequently blocking" kind of thread is best served by a work-stealing scheduler, but that may not be the best scheduler for other kinds of threads). When you implement fibers in the runtime, you can let the developer choose a scheduler for their needs.

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.)

I imagine Java can do some party tricks with lock sharing too with fibers backed by the same OS thread.

I'm kidding, his posts are awesome :)

The way I read it, tail call elimination is the guaranteed application of tail call optimisation with a well defined meaning of what a tail call is. Eg scheme requires TCE.

Tail call optimisation is a transformation a compiler may choose to do to make code that looks like “return foo(...)” run faster. A compiler may choose to not do it because it might not be implemented or faster or it could make debugging harder. There is no guarantee it will happen.

TCO makes some code faster. TCE allows one to write different looking programs knowing they won’t blow up the stack.

This all being said I think most people mean what I have referred to as TCE when they say TCO.

Yes, the elimination of the tail call is the optimization.

FWIW, Clojure handles this through syntax, so recursive algorithms are generally implemented with loop/recur forms that don't blow up the stack (instead of having a function literally call itself): https://clojuredocs.org/clojure.core/loop

We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp.

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.

In a Haskell context, since continuations are typically implemented as a monadic value, the statement would be more or less nonsensical. But I don't think that would be the context in question.

Edit: noelwelsh speaks of another level of composition than I was, where one is trying to take, say, State and STM and create a new monadic value that does both those things. The analysis given there is correct as well. My point here is more syntactic and basic functioning, in that even if you pick a single monadic value type to stick with, it's not going to play well in Java anyhow. So, in conclusion, generalized monad-type code in Java is just comprehensively not really possible. Continuations, or what are being called that in modern times, however, fit into Java-type languages, as proved by several very similar languages that have had them for many years, and they work fine.

Now I disagree with Ron's assertion that continuations compose better than monads. Here's why:

All monads can be expressed in terms of the continuation monad. As the name suggests this is just a monadic encoding of continuations. (See https://www.schoolofhaskell.com/school/to-infinity-and-beyon...).

If your language has continuations built-in then all programs are effectively running in some "ambient" monad that can express all other monads. Just like if you have exceptions you're effectively running within an error-handling monad.

So essentially rather than writing `F A` (or `F[A]` or `F<A>` or whatever syntax your language supports) to represent effectful programs all programs are implicitly running within such an effect type.

Clojure already supports forms of delimited continuations. You can use core.async for example, or cloroutine. That said, it can't yield across stack frames. One problem with that is that if you use a go block for example, calling anything inside it which will block can sabotage your go thread. With Project Loom, all blocking call made within a Fiber will yield it instead of blocking the thread. That would be the big advantage, and possibly something Clojure could leverage as well, so that say making a blocking IO call even indirectly inside a go block would park instead of blocking.

However, you might want to look up delimited continuations as a different approach to similar kinds of control flow.

The difference is very big from the programmer's perspective. Kotlin's coroutines are a syntactic concept; i.e. a piece of code is either a subroutine or a coroutine, and you can use one or the other in different syntactic contexts. Loom's continuations, however, are a purely dynamic construct, like a thread. You can run any piece of code inside a continuation. The implication is that no language change is required for continuations and the fibers that are based on them -- they are just a different implementation of threads -- and no API changes. In fact, even though this talk provides some background, developers don't need to learn about continuations at all to use them. All they need to know is that they can use a light-weight implementation of threads.

They're changing the JVM and Java specs, so what is forbidden or not will change.

Oleg Kiselyov has written about it extensively: http://okmij.org/ftp/continuations/

So whilst I haven't looked at the code, presumably continuations are pre-empted by forcing the host thread to a safepoint and then unmounting it.

Note that forced pre-emption + a scheduler + a userspace notion of a thread gives you the tiniest core of an operating system. The next big leap in operating system design is certainly language-generic virtual machines fused with the basics of an OS.

With the caveat that there are JVMs written in Java, so that line can be crossed:

https://www.jikesrvm.org/

The same mechanism could apply at the Spring Boot boundary. Using Spring Boot (for simple applications) is easy enough. Implementing it takes code that is beyond bizarre.

The only exception to this is dependency injection via annotations but for god’s sake use it in moderation.

But then I still prefer to write for loops rather than streams because I know what the jit compiler is doing.

https://www.reddit.com/r/java/comments/7ulmwn/coroutines_in_...

It's quite possible to make non-magical coroutines in Java. It's about how you document them (and perhaps how you try to hide implementation details).

It's just the opposite, Java programmers are doing something much more limited. Java has a deliberately simplified language design, but the result is that most serious Java systems have to use one or more frameworks that step outside of what's possible in Java proper (by using reflection, proxies, bytecode manipulation, JVM agents or other such shenanigans) to meet their requirements. And such frameworks are necessarily "magic" from the perspective of someone thinking in Java proper.

This room is called Spring MVC and it has 2 million switches which will let you do anything you please. Good luck.