Why Continuations Are Coming to Java • Hacker News Board

Re: Why Continuations Are Coming to Java

#131

Post by pron » Tue, Jul 02, 2019, 2:47 PM UTC

garmaine wrote: post #116

avodonosov wrote: post #68

Earlier quoted context omitted.

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.

Even 4k is a lot, and whatever memory is committed stays committed (and worse, it may even be paged). Perhaps it would be possible for the kernel to uncommit unused stack pages, but I don't think kernels want to assume threads never access memory below their stack pointer.

Re: Why Continuations Are Coming to Java

#132

Post by pjmlp » Tue, Jul 02, 2019, 2:50 PM UTC

pantulis wrote: post #124

pjmlp wrote: post #90

Earlier quoted context omitted.

Dylan did it first though.

Modula-2 had coroutines!

Indeed, but I was replying to "All languages are becoming Lisp, except for the added challenge of avoiding parentheses.".

Now if we are speaking about coroutines, there are other languages even older than Modula-2, although it was probably the most mainstream one at its peak.

Re: Why Continuations Are Coming to Java

#133

Post by pron » Tue, Jul 02, 2019, 3:04 PM UTC

jerf wrote: post #108

dfgdghdf wrote: post #98

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

In a Java context, I'd say it's undeniably true. Haskell-style composition of monadic values depends on type system features that Java doesn't have and on no account should even be thinking about adding at this point in time. And that's ignoring the syntax mess it would be in Java today, too. In a Haskell context, since continuations are typically implemented as a monadic value, the statement would be more or less no…

We're trying to minimize and discourage the use of monads, not encourage it :)

Having said that, monads don't compose well regardless of language.

Re: Why Continuations Are Coming to Java

#134

Post by pron » Tue, Jul 02, 2019, 3:07 PM UTC

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.

Re: Why Continuations Are Coming to Java

#135

Post by noisy_boy » Tue, Jul 02, 2019, 3:30 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!"

Having used Spring Boot for a while, I made up an analogy: Spring boot is a like a room which has a 1000 switches and a staircase leading to the basement. Usually these switches are enough for most use people. However, if your use case isn't served by them, you can follow the stairs to a much bigger room.

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

Re: Why Continuations Are Coming to Java

#136

Post by firethief » Tue, Jul 02, 2019, 3:37 PM UTC

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…

Nothing is right about call-cc: http://okmij.org/ftp/continuations/against-callcc.html

Re: Why Continuations Are Coming to Java

#137

Post by mruts » Tue, Jul 02, 2019, 3:45 PM UTC

Will this mean that Akka can support true multitasking like Erlang? If so, that sounds amazing. Being able to write blocking code in actors is such a big win.

Re: Why Continuations Are Coming to Java

#138

Post by chrisseaton » Tue, Jul 02, 2019, 3:48 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.

> If the benefits are this large, it should be provided by the OS in my opinion.

Like with most things, there are drawbacks as well as benefits.

Re: Why Continuations Are Coming to Java

#139

Post by [deleted] » Tue, Jul 02, 2019, 3:51 PM UTC

ygra wrote: post #83

avodonosov wrote: post #68

Earlier quoted context omitted.

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?

[deleted]

Re: Why Continuations Are Coming to Java

#140

Post by chrisseaton » Tue, Jul 02, 2019, 3:53 PM UTC

garmaine wrote: post #116

avodonosov wrote: post #68

Earlier quoted context omitted.

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.

No you have it backwards - the address space is always allocated. The physical memory is not allocated (we say committed) until it is used.

But allocating the address space even if it is not committed still consumes finite resources and still limits the number of threads you can create.