Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Continuations Are Coming to Java

infoq.com

Post reply on HN
Print view View original

151–160 of 185 posts

Re: Why Continuations Are Coming to Java

#151

Post by repolfx »

mapcars wrote: post #51

>if a continuation gets into an infinite loop, we can ask it to preempt itself, and forcefully remove it from the CPU. This is interesting, any idea of how they can do it?

That's easy. All Java threads regularly pass through "safe points" where the runtime can choose to suspend them. Think about garbage collection - the runtime must be able to reliably and regularly pause threads so their stacks can be scanned. Whether interpreted or JIT compiled, there are ways to queue a piece of code 'into' a thread that's currently running and a short time later that code will execute. Safe points are used for many different things in HotSpot.

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.

Re: Why Continuations Are Coming to Java

#152

Post by deathanatos »

lmm wrote: post #141
trias wrote: post #75

Earlier quoted context omitted.

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.

The OS doesn't know the details of what things are specific to a given "thread". So it has to take a "big dumb sledgehammer" approach to switching tasks: it has to switch out the whole stack (4k or 8k) even when there are only a few bytes that belong to that particular task (because it has no way of knowing which bytes those are), and it has to interrupt the tasks at essentially arbitrary times rather than waiting fo…

> it has to switch out the whole stack (4k or 8k) even when there are only a few bytes that belong to that particular task (because it has no way of knowing which bytes those are)

This reads to me like you believe the OS must memcpy/move the whole stack out of the way on a context switch. It doesn't; the other thread has other, dedicated memory its stack, and on a context switch, the stack pointer is simply adjusted to point at the other stack.

Assuming Java's fibers work similar to other green thread implementations, green threads/fibers work similarly — it's just a pointer change, except the adjustment is done in userspace.

(And, to some degree, the OS does know what bytes are stack for any given task. It's whole pages, yes, but that allows the program to manage it otherwise. But I think most green-thread/userspace threads are similar: the stack is preallocated ahead of time and left to the thread to manage. Sure, you might not know the exact range, but you don't really need to? Go, I think, is an interesting outlier here; IIRC, it dynamically expands and contracts the allocated space on the stack in response to the application's demands, though I do think they had some interesting issues w/ loops thrashing allocations if they fell along an allocation boundary. I think they've also long since fixed that issue.)

Re: Why Continuations Are Coming to Java

#153

Post by mamcx »

_delirium wrote: post #122
mamcx wrote: post #119

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?

One approach, which Java is taking, is to implement a more structured form of continuation, rather than say the Scheme-style call/cc ones. A quote from the article: "To be more precise, if you're interested in the theory of continuations in the academic literature, the kind of continuation of this class implements are called one-shot multi prompt delimited continuations..."

That kind of continuation don't have much info that I remember and probably I'm not the only one:

https://www.reddit.com/r/ProgrammingLanguages/comments/9r2kt...

but still look interesting if somehow manage to be performant-enough and tame enough. I think continuations are best for the internals of the compiler/vm than to surface to the end user...

Re: Why Continuations Are Coming to Java

#154

Post by michaelmrose »

Decabytes wrote: post #144

Is tail call elimination the same as tail call optimization? I know that schemes use this to keep the stack from blowing up during recursive function calls, and that currently the JVM, and by extension Clojure is not able to handle this. I also remember reading somewhere that this wasn't possible to add/not on the road map for the JVM. Does project Loom change this?

Clojure does explicit tail calls with recur.

Re: Why Continuations Are Coming to Java

#155

Post by TickleSteve »

scott_s wrote: post #149
TickleSteve wrote: post #78

Earlier quoted context omitted.

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.

That depends on the synchronization mechanism used, and whether or not that mechanism is hooked into the kernel scheduler. Sometimes it is (such as pthread_mutex) and sometimes it is not (such as rolling your own spin locks).

ok, any "sane" implementation would not use spin-locks for this purpose, but yes it is technically possible to do so.

Spin-locks are not really the mechanism of choice for this level of abstraction.

Re: Why Continuations Are Coming to Java

#156

Post by vkaku »

twic wrote: post #27

> I serve as a technical lead for Project Loon. That is the project that's intended to add continuations and fibers to the JDK. > However, actually, Project Loom, the goal of the project is to add continuations, fibers, and tail call elimination. I'm guessing that the project is called either Loom or Loon (and i believe it's the former), but i like the idea that there are actually two cooperating projects, each of wh…

I don't mind a stack size increase if we can push for better inlining/folding :D Also, stick to one name it's easier.

Re: Why Continuations Are Coming to Java

#157

Post by lesbaker »

twic wrote: post #27

> I serve as a technical lead for Project Loon. That is the project that's intended to add continuations and fibers to the JDK. > However, actually, Project Loom, the goal of the project is to add continuations, fibers, and tail call elimination. I'm guessing that the project is called either Loom or Loon (and i believe it's the former), but i like the idea that there are actually two cooperating projects, each of wh…

"Loon" is an error in transcription; if you listen to the video of the talk, he says "Loom", but with a British-sounding accent.

Re: Why Continuations Are Coming to Java

#158

Post by wahern »

jacques_chester wrote: post #84
trias wrote: post #75

Earlier quoted context omitted.

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.

OS scheduling requires you to switch contexts between different modes in the CPU. Essentially, the OS has the power to perform operations that regular code does not. Threads and processes are usually built on top of these additional permissions. Context switching is relatively expensive. The CPU needs to push a lot of application state out of the way to clear the path for the OS code to run, then after the OS is done…

Context switching doesn't need to be as expensive as it is in these cases, it's just that Linux doesn't provide the mechanisms needed to make it more efficient. See, e.g., https://blog.linuxplumbersconf.org/2013/ocw/system/presentat... which implemented a syscall for a process-directed context switch directly to another thread.

Re: Why Continuations Are Coming to Java

#159

Post by wahern »

deathanatos wrote: post #152
lmm wrote: post #141

Earlier quoted context omitted.

The OS doesn't know the details of what things are specific to a given "thread". So it has to take a "big dumb sledgehammer" approach to switching tasks: it has to switch out the whole stack (4k or 8k) even when there are only a few bytes that belong to that particular task (because it has no way of knowing which bytes those are), and it has to interrupt the tasks at essentially arbitrary times rather than waiting fo…

> it has to switch out the whole stack (4k or 8k) even when there are only a few bytes that belong to that particular task (because it has no way of knowing which bytes those are) This reads to me like you believe the OS must memcpy/move the whole stack out of the way on a context switch. It doesn't; the other thread has other, dedicated memory its stack, and on a context switch, the stack pointer is simply adjusted…

Java's fibers actually work like the previous poster described, which may explain the confusion:

> The current prototype implements the mount/dismount operations by copying stack frames from the continuation stack – stored on the Java heap as two Java arrays, an Object array for the references on the stack and a primitive array for primitive values and metadata. Copying a frame from the thread stack (which we also call the vertical stack, or the v-stack) to the continuation stack (also, the horizontal stack, or the h-stack) is called freezing it, while copying a frame from the h-stack to the v-stack is called thawing. The prototype also optionally thaws just a small portion of the h-stack when mounting using an approach called lazy copy; see the JVMLS 2018 talk as well as the section on performance for more detail.

Source: https://wiki.openjdk.java.net/display/loom/Main

The video presentation describes it better. I think in their expected usage scenarios the stacks of fibers aren't particularly deep so the copying isn't that expensive. Also, IIRC, doing it this way was less intrusive to the existing JVM architecture; it's possible in time they'll rearchitect things to use a more traditional technique.

Re: Why Continuations Are Coming to Java

#160

Post by stcredzero »

Because Java eventually implements everything that was done years ago in Smalltalk. Despite some having said it was unnecessary back then. Also, expect that a feature that was implemented in Smalltalk by a single dev as a library (this applies to continuations) will take a small team in Java. (Though the Java implementation may well be more robust and faster than the Smalltalk one from years ago.)
Post reply on HN