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

171–180 of 185 posts

Re: Why Continuations Are Coming to Java

#171

Post by garmaine »

pron wrote: post #131
garmaine wrote: post #116

Earlier quoted context omitted.

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.

Oh I agree OS threads a really heavyweight and there is a real need for fibers / green threads. I think we're arguing over whether they are 100x more efficient or 10,000x more efficient. Details matter ;) Thanks for your work on this for Java!

Re: Why Continuations Are Coming to Java

#172

Post by clhodapp »

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.

Constraints on the user free the platform. Freedoms for the user constrain the platform.

If you are interested in someone pontificating about this at length, see https://youtu.be/GqmsQeSzMdw

Re: Why Continuations Are Coming to Java

#173

Post by avodonosov »

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?

Good point, yes. As mentioned in a sibling comment, even 4k for one page of really allocated memory is significant.

Re: Why Continuations Are Coming to Java

#174

Post by avodonosov »

garmaine wrote: post #170
chrisseaton wrote: post #166

Earlier quoted context omitted.

Again, there's plenty of address space in 48 bits, but you need to commit physical memory in order to allocate the space for the page table for that address space. And that's per-process, and it's going to thrash the TLB.

That's not how the OS's page management tables work. The OS assigns space for the stack at a (typically random) location in the process' address space, but no physical allocation is made. The very first time the stack is used a page fault exception is generated, causing a context switch to the OS. Only then does the memory management subsystem allocate a page for the stack and return control back to the program. Hand…

These are good points, thank you.

BTW, I studied a little deeper, Java actually commits the stack memory upon thread creation.

The memory distribution of java process may be seen using jcmd VM.native_memory as suggested here http://xmlandmore.blogspot.com/2014/09/jdk-8-thread-stack-si...

But due to Linux memory overcommit this memory is not really allocated.

I've managed to create 127000 Java threads on my machine, and the resident memory of this process, as shown by `top` is 2,167G ~ 17k per thread.

If I disable memory overcommit, only around 32000 threads are created.

Re: Why Continuations Are Coming to Java

#175

Post by lostmsu »

garmaine wrote: post #171
pron wrote: post #131

Earlier quoted context omitted.

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.

Oh I agree OS threads a really heavyweight and there is a real need for fibers / green threads. I think we're arguing over whether they are 100x more efficient or 10,000x more efficient. Details matter ;) Thanks for your work on this for Java!

I think you severely overestimate the efficiency gain both times.

Re: Why Continuations Are Coming to Java

#176

Post by wmfiv »

hderms wrote: post #129
nimbix wrote: post #125

What ever happened with continuations in Scala? A lot of people were excited about them back in 2009, but if I google them now I still only get pages from 10 years ago. I haven't used Scala in a very long time, so I stopped paying attention to any changes in the language.

as far as I can tell scala concurrency basically boils down to a few different subclasses that have some overlap: 1. streaming/observable focused like Monix 2. IO effect type like Cats Effect and ZIO 3. Twitter futures/Stdlib futures which are different from each other in some crucial ways

Probably need to add 4. Akka.

Re: Why Continuations Are Coming to Java

#177

Post by garmaine »

lostmsu wrote: post #175
garmaine wrote: post #171

Earlier quoted context omitted.

Oh I agree OS threads a really heavyweight and there is a real need for fibers / green threads. I think we're arguing over whether they are 100x more efficient or 10,000x more efficient. Details matter ;) Thanks for your work on this for Java!

I think you severely overestimate the efficiency gain both times.

It's a bit dated, but here's a reference:

https://blog.tsunanet.net/2010/11/how-long-does-it-take-to-m...

Re: Why Continuations Are Coming to Java

#178

Post by garmaine »

avodonosov wrote: post #174
garmaine wrote: post #170

Earlier quoted context omitted.

That's not how the OS's page management tables work. The OS assigns space for the stack at a (typically random) location in the process' address space, but no physical allocation is made. The very first time the stack is used a page fault exception is generated, causing a context switch to the OS. Only then does the memory management subsystem allocate a page for the stack and return control back to the program. Hand…

These are good points, thank you. BTW, I studied a little deeper, Java actually commits the stack memory upon thread creation. The memory distribution of java process may be seen using jcmd VM.native_memory as suggested here http://xmlandmore.blogspot.com/2014/09/jdk-8-thread-stack-si... But due to Linux memory overcommit this memory is not really allocated. I've managed to create 127000 Java threads on my machine, a…

Thanks for digging deeper into it, that’s some good info.

Re: Why Continuations Are Coming to Java

#179

Post by provolone »

geodel wrote: post #143
provolone wrote: post #61

Earlier quoted context omitted.

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.

Feels like today there are some libraries that are only offered for Spring. Other than that I have been happy to do as you do with Jetty.

I'll add that autoconfiguration is a symptom, not a solution.

Re: Why Continuations Are Coming to Java

#180

Post by rjn »

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…

There are ways to compose monads, https://en.wikibooks.org/wiki/Haskell/Monad_transformers
Post reply on HN