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

141–150 of 185 posts

Re: Why Continuations Are Coming to Java

#141

Post by lmm »

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.

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 for them to yield (because, again, it has no way of knowing what the yield points are) which then means the tasks have to have more synchronization overhead etc. to work around the fact that they might be preempted at any point.

In this age of VMs/containers for everything I'm not convinced a conventional OS offers a lot of value - OSes made sense when programs needed to access different kinds of hardware and we liked to have multiple processes/users sharing a single machine while broadly trusting each other, but neither of those things is really true any more. Look at unikernels for where I think the future is going - bootable VMs that act as a language runtime that controls things like threading directly, no need for an OS intermediary.

Re: Why Continuations Are Coming to Java

#142

Post by jimmaswell »

pron wrote: post #70
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 are a couple of issues here: scheduling, and managing the stack. The reason a runtime can do better than the kernel is that its constraints are (hopefully) less constraining than those of the kernel. 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 dynamical…

That sounds like the runtime has more constraints thus it can make more assumptions, not less constraints, while the OS one must be more general.

Re: Why Continuations Are Coming to Java

#143

Post by geodel »

provolone wrote: post #61
cryptos wrote: post #16

Earlier quoted context omitted.

This is not a balanced argument. Spring offers a lot of helpful things and can increase productivity. But it also has it's downsides like when something is not working because all the magic behind the scenes, making you more productive normally, just doesn't work in your case. If I look at Go code, for example, I can hardly bear all the tedious repetition and dumb code! There is hardly any magic in Go, but the downsi…

That's fine. Use what works for you. There's more than one way to skin a cat. It isn't particularly balanced to assume that the spring way is the only way to do things because magicians... If the OP has that problem with spring then he can use the base servlet API or another solution.

I do exactly same as you described. Use plain servlets with embedded tomcat in application. It all works very well for me.

But now I have to support multiple Spring boot projects. I can't help noticing one thing common in these projects that it is about 10% functionality and 90% of Spring turd nuggets strewn all over project repos.

Re: Why Continuations Are Coming to Java

#144

Post by Decabytes »

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?

Re: Why Continuations Are Coming to Java

#145

Post by dan-robertson »

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?

Yesish.

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.

Re: Why Continuations Are Coming to Java

#146

Post by timgilbert »

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?

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

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

Re: Why Continuations Are Coming to Java

#147

Post by repolfx »

vlaaad wrote: post #37
cryptos wrote: post #17

What is called continuations in Java is available as "coroutines" in Kotlin, today. Both terms means more or less the same, from a programmers point of view, actually Continuations are part of Kotlins coroutines. https://kotlinlang.org/docs/reference/coroutines-overview.ht...

What is a language feature of Kotlin is available as a library in Clojure: https://github.com/clojure/core.async/

Almost all of Kotlin's coroutines support is also in a library. The stuff that comes from the compiler is really the smallest possible slice, required because there is syntax for it.

Re: Why Continuations Are Coming to Java

#148

Post by lilactown »

jimmaswell wrote: post #142
pron wrote: post #70

Earlier quoted context omitted.

There are a couple of issues here: scheduling, and managing the stack. The reason a runtime can do better than the kernel is that its constraints are (hopefully) less constraining than those of the kernel. 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 dynamical…

That sounds like the runtime has more constraints thus it can make more assumptions, not less constraints, while the OS one must be more general.

It depends on your perspective.

The OS one has more _requirements_ (the number of "it must do..." is much higher), which constrains it's design space much more. I think you can call that as "having more constraints" because it must meet more needs to be even viable as a solution.

The number of requirements for JVM threads is much lower, thus less constraining, allowing it more freedom to implement solutions that can meet its narrower window of features.

Re: Why Continuations Are Coming to Java

#149

Post by scott_s »

TickleSteve wrote: post #78
aardvark179 wrote: post #71

Earlier quoted context omitted.

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.

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

Re: Why Continuations Are Coming to Java

#150

Post by exabrial »

pron wrote: post #134
exabrial wrote: post #103

How will ThreadLocal behave under different fiber context switches?

A fiber will appear to be a thread. You can even call Thread.currentThread and get a consistent Thread object representing the fiber. This is done so that as much existing code as possible would be able to run, unchanged, in fibers. We may (or may not), however, introduce newer, better constructs that new code will be encouraged to use.

Oooo cool! It may be important or useful to include the 'old' contract elsewhere in the SDK.
Post reply on HN