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

81–90 of 185 posts

Re: Why Continuations Are Coming to Java

#81

Post by giancarlostoro »

pron wrote: post #58
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...

While continuations and coroutines are often used interchangeably (continuations are usually one-shot delimited continuations), Loom's continuations are very different from Kotlin's coroutines, which are more similar to C#'s async/await (they are stackless ), while the fibers built on top of Loom continuations are more like Erlang's processes or Go's goroutines. The difference is very big from the programmer's perspe…

Any idea how these fibers compare to the ones used by D as well? I also wonder if this means Kotlin will adopt Fibers since it does build on top of JVM capabilities.

Re: Why Continuations Are Coming to Java

#82

Post by avodonosov »

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…

pron, isn't it simpler to just allocate everything on heap, than reallocating coroutine stacks? Or is allocating on heap significantly less performant than managing coroutine stacks (stack need to be copied, while heap allocated object can stay the same).

Also, is there any timeline or estimate when Loom will be released with official JDK?

Re: Why Continuations Are Coming to Java

#83

Post by ygra »

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.

You only lose address space as long as that stack memory isn't used, right?

Re: Why Continuations Are Coming to Java

#84

Post by jacques_chester »

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.

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, push the OS out of the way and retrieve the application's state and code again.

Whereas a fiber remains entirely inside the application code. It never requires a context switch. But a fiber loses some of the powers of the OS: for example, it can't draw hard memory boundaries between fibers that will be enforced by the CPU.

For some things you want processes, for some threads, for some fibers.

Re: Why Continuations Are Coming to Java

#86

Post by jacques_chester »

earenndil wrote: post #34
saagarjha wrote: post #21

Earlier quoted context omitted.

Assembly and C have plenty of magic to go around, don't worry.

C yes, assembly--where? Its mapping to machine code is relatively straightforward, and as is the mapping from machine code to ELF. Or do you mean all the magic the CPU does to make it go fast?

Assembler code used to be a close mapping of what the CPU does. But it too is now a high-level language with a funny syntax, it's just that the complexity is hidden by the CPU frontend instead of by a language compiler.

Re: Why Continuations Are Coming to Java

#87

Post by twic »

james-mcelwain wrote: post #31
groestl wrote: post #25

Earlier quoted context omitted.

The JVM is not magic, neither are Java programmers magicians, but I think the reason magical terms are used to describe Java systems is that the ecosystem had lots and lots of time to develop libraries and abstractions (a few of which happen to be of the right kind, read: leak just the right amount). Your typical Java programmer is well aware what it takes to implement a battle-proof connection pool, and will not att…

The way I would phrase it is that the Java ecosystem is simultaneously both higher level and lower level (in terms of abstraction, not the machine) than many other platforms. The ability to swap out basically any component of a framework like Spring simply by including a different dependency or replacing a bean at runtime allows for fine grained tuning that isn't possible in many other frameworks. But this flexibilit…

The Java library developer's aesthetic has traditionally been to make things possible, rather than to make things easy. So you may have to write a lot of code or config to get something to happen, but you will have a lot of control over what happens.

This is the opposite emphasis to, say, the Ruby community, which values a simple, lickable, surface interface with a large amount of opaque magic hiding behind it.

Re: Why Continuations Are Coming to Java

#88

Post by jacques_chester »

AlEinstein wrote: post #13
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!"

Speaking as a dev who started with Java 1.2, I actually much prefer to write code that doesn’t rely on magic unseen effects. 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.

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

Dependency injection comes in two varieties: constructor injection and future pain injection.

Choose wisely.

Re: Why Continuations Are Coming to Java

#89

Post by pjmlp »

jonathanstrange wrote: post #46

Seems like every sufficiently advanced language at one time or another turns into LISP.

"Invited Talk - Guy Steele" at ClojureTV.

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.

Post reply on HN