Feature request: Re-enterable Contexts

[faceless2]

The current API revolves around Value value = context.exec(Source), where a context is entered, run and a value returned.

There doesn't seem to be any way for the exec stage to be paused and resumed. The specific case I have in mind is interacting with an object from the host environment which needs to retrieve a resource, and that could take some time. It would be great if that object could return a Future to the context, the context.exec method would complete and could be resumed when the future completes.

I find it easier to explain with code

Context context = Context.create("js");
RuntimeContext rctx = context.createRuntime(source);  // sets up the context but doesn't start it
context.getBindings("js").putMember("foo", new MyObject(rctx));
while (!r.isComplete()) {
    r.exec();   // Run the context until it completes or is paused
}
Value value = r.getValue().get();  // Retrieve the value that would have been returned from context.exec(source);

class MyObject {
    MyObject(RuntimeContext rctx) {
       this.rctx = rctx;
    }
    Object getValue() {
        Future<?> future = rctx.suspend();
        evaluateFutureInAnotherThread(future);  // Begin background task, will eventually complete the future
        return future;   // When Graal sees this, RuntimeContext is suspended.
    }
}

interface RuntimeContext {
    boolean isCompleted();  // True if the context is complete and getValue() won't block
    void exec(); // Run the context until it completes or is suspended;
    Future<?> suspend();   // When the HostObject sees this value returned from a method it suspends the context
    Future<Value> getValue();  // Return a future to get the value.
}

This opens a lot of very interesting possibilities.

• Interleaving evaluation of multiple Contexts, all waiting for resources, on a single thread. Like libc select(2) for contexts.
• Load management - a suspended context can be delayed until the resources are necessary to restart it
• If you could serialize Context as well as RuntimeContext, this would let you Serialization/Migration of contexts mid-execution.
• The idea of a RuntimeContext can be extended to do a lot of the things you're doing now in ContextBuilder. For example, rather than declaring a filesystem-access policy up-front, RuntimeContext could have a boolean isFileAccessAllowed(Path path, int mode) so decisions can be made dynamically

There are obvious wrinkles, the main one being if the context has queued tasks for later execution eg with JS setTimeout() - delaying these until resumption will be reasonable in some circumstances, not others. TBD.

This seems fairly similar conceptually to Truffle safepoints and poll(), which I see are used internally - but there's no obvious way to interact with those from user-space, i.e. from the same thread that called Context.exec(). So I'm hoping something like this idea could be put alongside Context.exec().

Related: #9317