3 ms·

I'm surprised Loom hasn't been mentioned yet in this thread. Proposal: http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html http://cr.openjdk.java.net

I'm surprised Loom hasn't been mentioned yet in this thread. Proposal: http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.htm... It's in the early phase, but there is a prototype currently. The commits in the mailing list mention a recent zero copy continuation thawing if I'm not mistaken. http://mail.openjdk.java.net/pipermail/loom-dev/2018-October/thread.html http://mail.openjdk.java.net/pipermail/loom-dev/2018-October... EDIT: I'm mistaken, it is about lazy stack walking (but I remember zero copy continuation thawing might be attempted)

aardvark179 8y ago
Heap allocated stacks require teaching the garbage collectors new tricks since they need to parse the frames for references, whereas those can be handle during the freeze/thaw operation if we copy the stack. We think we can achieve the level of performance we want with stack copying.
- cryptonector 8y ago
  Stack copying strikes me as oh so wrong... Anyways, allocating frames or stacks on the heap doesn't seem like it should require teaching the GC all that much. They would essentially be objects of such a class that the GC can traverse them... just like a normal stack (from current frame through return closures), which it already has to know how to do. Their location shouldn't be so important.