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.
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-passi... Or read about how Scheme compilers work to support first class continuations, and the tricks you can play with them.
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.
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.
