We need a high performance way to execute the JavaScript portion of a static analysis rule, so we are re-using the same v8 isolate across executions.
The ideal model for us is to create a new Context and Context::Scope for every rule execution. v8 Contexts (background info here) are relatively cheap to create, and as soon as they drop out of scope, all local handles are able to be garbage collected.
Each context has effectively its own state, and each context its own global environment. This is problematic for us, because when we bootstrap the deno_core runtime, we populate the v8 isolate's default context's global environment with DDSA-specific variables (see __bootstrap.js).
Because of this, we either need to share a global environment across contexts, or allocate and re-assign the global object with all of our needed values every time we create a new context. I previously didn't know v8 well enough to know how to achieve the former (hence why I re-used a v8 Context across executions and used a hacky closure-based solution to simulate different v8 Contexts).
This PR addresses this problem.
What is your solution?
Ideal solution
The ideal solution would be to pass in a handle to a pre-allocated global object ("global_object") when the v8 context is created. This is possible in the C++ API. We'd do something like the following:
auto ddsa_global = prev_ctx->Global();
prev_ctx->Exit();
prev_ctx->DetachGlobal();
auto new_ctx = v8::Context::New(/* ...isolate, ...template */, ddsa_global)
However, this is not possible with rusty_v8. As of writing, v8::Context::new will always pass in null for the "global_object" parameter.
rusty_v8 does have v8::Context::new_from_template, which would let us pass in an ObjectTemplate, however that isn't ideal for two reasons: 1) it would allocate an entirely new object and 2) ObjectTemplates can only store primitives or other ObjectTemplates/FunctionTemplates. 2 would be a significant thorn because the ddsa lib is designed around stateful "bridge" objects being available to all JavaScript executing, and hydrating their state from scratch would be complicated.
Thus, to get around rusty_v8's inability to pass in a pre-allocated object to be used as the global object, we simulate this behavior by manually setting the prototype of a context's global proxy object to our pre-allocated object. In order to re-use this object across contexts, we have to make it a v8::Global.
Wait, global this, global proxy that...uhh...what?
"Global"
Yes, this terminology is quite confusing. Quick summary:
v8::Global - The name rusty_v8 has given to a v8 Persistent handle. TL;DR a value that has been forgotten by the garbage collector and so we can re-use it between v8 Contexts.
Global Object - The "true" global object, which holds all v8 global values (functions and variables) for a specific v8 Context. See v8's bootstrapper.cc for some additional commentary.
Global Proxy - An object that intercepts property access to the "true" global object. v8 uses this for encapsulation and security. In JavaScript, this is exposed as the variable globalThis. rusty_v8 somewhat imprecisely calls this "global" (accessed with Context::global).
So in sum, we are creating a "persistent" v8 object, and we configure each v8 Context to use this v8 object. Within the execution context, mutations to this v8 object can happen, but they never persist beyond the context. Executions are thus isolated from each other.
Benefits
By doing this, we no longer have to use a closure to encapsulate the rule's code. I suspect this will be a lot easier for v8's JIT to optimize.
A helper function for creating a v8::UnboundScript was added. UnboundScripts will be used so we only have to compile a v8 script once per rule, not once per execution as we currently do.
What problem are you trying to solve?
We need a high performance way to execute the JavaScript portion of a static analysis rule, so we are re-using the same v8 isolate across executions.
The ideal model for us is to create a new
ContextandContext::Scopefor every rule execution. v8 Contexts (background info here) are relatively cheap to create, and as soon as they drop out of scope, all local handles are able to be garbage collected.Each context has effectively its own state, and each context its own global environment. This is problematic for us, because when we bootstrap the
deno_coreruntime, we populate the v8 isolate's default context's global environment with DDSA-specific variables (see__bootstrap.js).Because of this, we either need to share a global environment across contexts, or allocate and re-assign the global object with all of our needed values every time we create a new context. I previously didn't know v8 well enough to know how to achieve the former (hence why I re-used a v8 Context across executions and used a hacky closure-based solution to simulate different v8 Contexts).
This PR addresses this problem.
What is your solution?
Ideal solution
The ideal solution would be to pass in a handle to a pre-allocated global object ("global_object") when the v8 context is created. This is possible in the C++ API. We'd do something like the following:
(See documentation for
static Local< Context > New)However, this is not possible with
rusty_v8. As of writing,v8::Context::newwill always pass in null for the "global_object" parameter.rusty_v8does havev8::Context::new_from_template, which would let us pass in anObjectTemplate, however that isn't ideal for two reasons: 1) it would allocate an entirely new object and 2) ObjectTemplates can only store primitives or other ObjectTemplates/FunctionTemplates. 2 would be a significant thorn because theddsalib is designed around stateful "bridge" objects being available to all JavaScript executing, and hydrating their state from scratch would be complicated.Thus, to get around
rusty_v8's inability to pass in a pre-allocated object to be used as the global object, we simulate this behavior by manually setting the prototype of a context's global proxy object to our pre-allocated object. In order to re-use this object across contexts, we have to make it av8::Global.Wait, global this, global proxy that...uhh...what?
"Global"
Yes, this terminology is quite confusing. Quick summary:
v8::Global- The namerusty_v8has given to a v8Persistenthandle. TL;DR a value that has been forgotten by the garbage collector and so we can re-use it between v8 Contexts.bootstrapper.ccfor some additional commentary.globalThis.rusty_v8somewhat imprecisely calls this "global" (accessed withContext::global).So in sum, we are creating a "persistent" v8 object, and we configure each v8 Context to use this v8 object. Within the execution context, mutations to this v8 object can happen, but they never persist beyond the context. Executions are thus isolated from each other.
Benefits
By doing this, we no longer have to use a closure to encapsulate the rule's code. I suspect this will be a lot easier for v8's JIT to optimize.
Alternatives considered
What the reviewer should know
execute_rulefunction onJsRuntime, which will be a thin wrapper around thescoped_executefunction introduced in this PR.v8::UnboundScriptwas added. UnboundScripts will be used so we only have to compile a v8 script once per rule, not once per execution as we currently do.