Why Continuations Are Coming to Java • Hacker News Board

Re: Why Continuations Are Coming to Java

#111

Post by ufo » Tue, Jul 02, 2019, 1:50 PM UTC

maxiepoo wrote: post #105

aardvark179 wrote: post #74

Earlier quoted context omitted.

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.

By one-shot you mean dynamically enforced, right? I.e. if you invoke it a second time it will raise an exception?

Not exactly, since they are using a fiber API instead of one built with raw continuations. In this context, being one-shot means that there is no operation for cloning or "forking" a fiber.

Each time you resume the execution of a fiber, it continues to execute until it reaches its next yield point. There is no way to go "back in time" and resume execution from a previous state of the fiber, which is what multishot coroutines or the fork system call would let you do.

Re: Why Continuations Are Coming to Java

#112

Post by garmaine » Tue, Jul 02, 2019, 1:51 PM 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.

They do: it’s called threads.

It’s the OS context switch that makes process threads so much more costly than user-scheduled fibers. You cannot involve the OS if you want efficiency.

Otherwise it is the same exact thing.

Re: Why Continuations Are Coming to Java

#113

Post by oddthink » Tue, Jul 02, 2019, 1:53 PM UTC

ghusbands wrote: post #107

oddthink wrote: post #106

Does anyone have a good link to the state of the modern thinking on continuations? I remember from back in the Scheme R5RS era there was a conflict between call/cc and dynamic-wind. If you have a dynamic extent (like for example a try {} finally {} block that does resource allocation/deallocation), and you exit, but then jump back into the block, how far do you try to re-wind the state? You probably don't re-open fil…

Dynamic-wind was created to tame call/cc and exceptions, rather than being in conflict with it. It directly provides the facilities for re-re-setting things when you re-enter a left scope. However, you might want to look up delimited continuations as a different approach to similar kinds of control flow.

Yes, thank you. I was thinking of Kent Pitman's critique that unwind-protect didn't have the right semantics when implemented with dynamic-wind, and that (in general) it seemed like fluid-let and unwind-protect wanted different sorts of continuations to implement them. (And now I need to go read more about one-shot vs multi and delimited continuations.)

Someone (I forget who) had a critique about dynamic-wind itself that (IIRC) involved capturing continuations from within the before- and after-thunks of dynamic-wind, but that seems more like an edge case.

Re: Why Continuations Are Coming to Java

#114

Post by ufo » Tue, Jul 02, 2019, 1:53 PM UTC

gigatexal wrote: post #26

So it’s like python’s yield statement aka generators?

It seems that these are stackless so there is no distinction between regular functions and generator functions. You can yield from many levels deep in the call stack, without needing to use "yield from"

Re: Why Continuations Are Coming to Java

#115

Post by pron » Tue, Jul 02, 2019, 1:54 PM UTC

noelwelsh wrote: post #109

dfgdghdf wrote: post #98

In the talk he says that continuations compose much better than monads. Can someone elaborate on this?

Monads don't compose, in the sense that if you two monads of different types you can't always mash them together to create a single monad that encompasses both of the effect the two monads represent. This is not surprising as (side-)effects don't in general compose so there is no reason that monads should. Now I disagree with Ron's assertion that continuations compose better than monads. Here's why: All monads can be…

It's true that monads and delimited continuations are equivalent, but what we have here aren't any delimited continuations but what's known as multi-prompt delimited continuations, and I call them "scoped continuations" (http://blog.paralleluniverse.co/2015/08/07/scoped-continuati...). Those compose well, and their pure-FP counterpart is algebraic effect systems (based on monads, but don't use monad transformers).

Re: Why Continuations Are Coming to Java

#116

Post by garmaine » Tue, Jul 02, 2019, 1:54 PM UTC

avodonosov wrote: post #68

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?

OS threads use statically allocated stack. This limits the nubmer of threads one can have (say if stack is 1MB and you have 1GB of memory, you can have 1024 threads max). That's the main difference. I think some savings also come from avoiding full blown context switches.

This is demonstrably not true. That address space isn’t allocated until it is used. Even with initial allocations of 4kB pages, there’s plenty more space than you’re estimating.

Re: Why Continuations Are Coming to Java

#117

Post by lmm » Tue, Jul 02, 2019, 1:54 PM 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…

I found iteratees to be the best of all worlds: you get the performance advantages of continuation-passing style, but you can still extract the start, middle, or end of a stream pipeline as an ordinary value that makes sense to reason about and test.

Re: Why Continuations Are Coming to Java

#118

Post by jarym » Tue, Jul 02, 2019, 1:56 PM UTC

avodonosov wrote: post #67

digaozao wrote: post #62

Earlier quoted context omitted.

Maybe with kotlin coroutines you can rewrite the application partially. Is there a difference between that and fibers?

Kotlin coroutines, as well as js and c# async/await, require us to change declaration of calling function. We can call a "suspend" function only from a "suspend" function, which in turn can only be called by another "suspend" function. So if I change some of my functions to "suspend" everyone upper in the call stack should be changed to "suspend", which is not always possible because that may be a 3rd party code. Tha…

Quasar was created by the same guy (Ron Pressler) that is the tech lead for Project Loom. The reason Quasar feels a bit abandoned is because he's bringing the thinking right into the JVM.

Re: Why Continuations Are Coming to Java

#119

Post by mamcx » Tue, Jul 02, 2019, 1:58 PM UTC

One thing I get learning about implementing continuations is that at the end them have huge runtime cost and complicate implementation and debugging greatly.

Even do a simple interpreter with them quickly get out of control.

Exist update info in how tame it?

Re: Why Continuations Are Coming to Java

#120

Post by lmm » Tue, Jul 02, 2019, 1:58 PM UTC

y4mi wrote: post #8

I find it amusing that whenever people talk about Java, they're somehow using magic to describe it. It's like Java programmers see themselves as magicians... This is especially widespread with spring boot. I've even read sentences like "It's hard to say what it does, you can only see it's effects!"

> I find it amusing that whenever people talk about Java, they're somehow using magic to describe it. It's like Java programmers see themselves as magicians...

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.