Some dynamic languages need stack reification

https://blogs.oracle.com/jrose/entry/continuations_in_the_vm (forthcoming)

Some important dynamic languages allow programs to inspect the control stack. (For example, a method might check whether it was invoked by a given caller.) Such stack inspection requires either that every method take costly steps to record its internal state on the current thread, or else that some sort of debugging mechanism allow the current thread to be inspected on an as-needed basis. The latter is preferable for performance reasons, much as Hotspot makes few compromises in compiled code quality, and relies on as-needed stack walking or deoptimization to cover the occasional requests for stack information.

Hotspot's stack walking mechanism should be surfaced (somehow) to an API that language implementors can use for stack inspection. The existing debugger interfaces do this, but they designed for loosely-coupled client processes. A tightly-coupled access path is needed.

Second use case: The Scheme language allows a program to form a handle to the future of a thread's execution. This handle, called a "continuation" is opaque, and does not support inspection, but it does allow the thread's computation to be reset back to the execution state (of the control stack) where the continuation was formed.

Third use case: Some programming frameworks for Java, notably http://rifers.org/, support continuations as a natural notation for web sessions and other intermittent or restartable processes. They current do this by transforming Java bytecodes into a stackless format. There would be less need for bytecode rewriting if the JVM stack did not get in the way, and editable continuations seem the likely native expression in the JVM of such patterns.

A prototype to support these use cases is under construction, based on the pair of unsafe functions copyStack and resumeStack. See Suggested Fix.

The key object revealed (reified) by the JVM (in CopyStackException.stack) is an array of objects, starting with a byte array of serialized structure information. (Indexes in the serialization call out to other elements of the object array.) The format is non-opaque, and allows new JVM stack states to be created from whole cloth, supporting a low-level form of thread mobility. Previously captured states can be modified, supporting advanced performance tuning or configuration management, as Hotspot does internally at present.