You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Patch name: callcc.patch

Basic usage

Creating a continuation

Continuation are supported via two different ways:

  • public native Object copyStack(Object context, CopyStackException ex) throws CopyStackException;
    This method packs all the stack frames from the current stack frame down to the context frame (see below) into an Object[] using the same serialized form that the Hotspot JVM uses to store debug information internally. This Object[] is then stored in the stack field of the given CopyStackException which is in turn thrown.
  • public native Object copyStackSimple(Object context, Continuation continuation);
    Fills the given Continuation object with the stack frames down to the context frame. Right now the method returns null, although it would probably be better to return a special static object instance instead of occupying null.

(warning) In the long run most likely only one implementation will survive.

Resuming continuations

The public long resumeStack(Object context, Object stack, Object value, Throwable exception); method is used to resume a continuation. (no matter how it was created). The current stack is destroyed up to the context frame and the continuation contained in the stack object is reinstated.
The original copyStack or copyStackSimple call then returns value or throws exception.

Creating a context for continuations

Unsafe.doCopyStackContext is used to create a context stack frame for continuations. The first parameter is a Runnable whose run method will be invoked, and the second parameter is a context object (any Object) that will identify this particular doCopyStackContext invocation.

Security

The current proof-of-concept implementation will be used to explore how continuations can be used in a secure environment (applet, etc.).
Starting from a very conservative approach features will be added if they are considered secure.

Permissions

The targets and actions for continuation permissions could be characterized roughly like this:

JVM Assumptions broken by continuations

Arbitrary continuations can break many low-level assumptions taken by the JVM and the continuation code, some of which could be verified and some not:

verifyable (with reasonable effort)

  • local variable count
  • expression count
  • static data types of local variables
  • expression is object or scalar
  • method can be executed for "this"
  • copyStack is called at the top frame
  • bottom frame method is a Runnable.run()

not verifyable (with reasonable effort)

  • data types of expressions
  • local variable or expression matches assumptions about data type

Conservative approach

The first security concept will be a very conservative one:

  • only methods marked with a Continuable annotation can be stored
  • Continuation objects do not allow any modifications
  • methods marked with ContinuableHidden can be stored but the local variables and the expression stack are hidden
  • no stack containing doPrivileged calls can be stored

Future considerations

  • create a notion of immutable continuations which allow the compiler to create shortcuts (like exceptions the compiler could statically prove that the continuation never escapes and thus convert it into a jmp, etc.)

Work in progress

  • No labels