4 ms·

There was a presentation with more info at last JVM Language Summit https://www.youtube.com/watch?v=X4tmr3nhZRg https://www.youtube.com/watch?v=X4tmr3nhZRg T

There was a presentation with more info at last JVM Language Summit https://www.youtube.com/watch?v=X4tmr3nhZRg https://www.youtube.com/watch?v=X4tmr3nhZRg The scary things is that they have implemented coroutine (generalized async/await) by copying the stack back and forth instead of putting the stack in the heap like in stackless python or in scheme.

tuyguntn 9y ago
For non-experts in this field could you please explain why its scary if it works great for their use cases?
- titzer 9y ago
  Putting it in the heap would generally be safer, as there are fewer special cases to worry about in the garbage collector. Making a copy of the stack and managing it "manually" probably means a lot of special scanning logic in the GC.
srean 9y ago
Could you please explain which stack you are talking about here. If I am not wrong, Java language semantics does not have stack allocated variables, hence my confusion. I sampled the video at random offsets but could not find the location where coroutine implementation was discussed.
- noelwelsh 9y ago
  It is the call stack that is being copied. It doesn't have to do so much with stack allocated variables (which may be created in Java according to the whim of the compiler) but with capturing the current state of a computation in a relatively light weight manner, so that light weight threads / coroutines can be saved and restored without the context switch and memory overhead of a full thread. This is basically the old "green threads" implementation used in the early JVMs. The big idea behind this is the concept of a continuation, and a conversion between programs in "direct style" (the way you normally write them) and "continuation passing style" which makes control flow explicit. You could start reading here if interested: http://matt.might.net/articles/by-example-continuation-passing-style/ http://matt.might.net/articles/by-example-continuation-passi... Or read about how Scheme compilers work to support first class continuations, and the tricks you can play with them.
  - srean 9y ago
    That makes sense. I wasn't sure which stack parent was referring to, stack of java activation records, the underlying C call stack of a JVM implemented in C.
- aardvark179 9y ago
  Java has a stack (it uses a stack based bytecode after all) which is used to hold arguments and so forth, and it has local variables whose values live on the stack. What it doesn't have is object allocation on the stack - so if a local variable is a reference type then the object it refers to will be created on the heap. Note the above only refers to the logical view of the language. A VM and JIT will have an ABI for method calls which may use registers to pass arguments (it may have several for interpreted and JITed code), and it can allocate objects purely on the stack if it can do good enough escape analysis.
sreque 9y ago
It's also far far slower performance-wise to put it on the heap. GoLang also does stack-copying with their continuations, and it's probably the best implementation strategy we have right now. There were a number of interesting projects at Da Vinci, including full TCO. I wonder how much further along Java would be if more of those projects got merged into mainline.

tuyguntn 9y ago

For non-experts in this field could you please explain why its scary if it works great for their use cases?

titzer 9y ago
Putting it in the heap would generally be safer, as there are fewer special cases to worry about in the garbage collector. Making a copy of the stack and managing it "manually" probably means a lot of special scanning logic in the GC.

srean 9y ago

Could you please explain which stack you are talking about here. If I am not wrong, Java language semantics does not have stack allocated variables, hence my confusion. I sampled the video at random offsets but could not find the location where coroutine implementation was discussed.

noelwelsh 9y ago
It is the call stack that is being copied. It doesn't have to do so much with stack allocated variables (which may be created in Java according to the whim of the compiler) but with capturing the current state of a computation in a relatively light weight manner, so that light weight threads / coroutines can be saved and restored without the context switch and memory overhead of a full thread. This is basically the old "green threads" implementation used in the early JVMs. The big idea behind this is the concept of a continuation, and a conversion between programs in "direct style" (the way you normally write them) and "continuation passing style" which makes control flow explicit. You could start reading here if interested: http://matt.might.net/articles/by-example-continuation-passing-style/ http://matt.might.net/articles/by-example-continuation-passi... Or read about how Scheme compilers work to support first class continuations, and the tricks you can play with them.
- srean 9y ago
  That makes sense. I wasn't sure which stack parent was referring to, stack of java activation records, the underlying C call stack of a JVM implemented in C.
aardvark179 9y ago
Java has a stack (it uses a stack based bytecode after all) which is used to hold arguments and so forth, and it has local variables whose values live on the stack. What it doesn't have is object allocation on the stack - so if a local variable is a reference type then the object it refers to will be created on the heap. Note the above only refers to the logical view of the language. A VM and JIT will have an ABI for method calls which may use registers to pass arguments (it may have several for interpreted and JITed code), and it can allocate objects purely on the stack if it can do good enough escape analysis.

sreque 9y ago

It's also far far slower performance-wise to put it on the heap. GoLang also does stack-copying with their continuations, and it's probably the best implementation strategy we have right now. There were a number of interesting projects at Da Vinci, including full TCO. I wonder how much further along Java would be if more of those projects got merged into mainline.