The use case is bug 521234.
It is possible already, see JSOPTION_COMPILE_N_GO.
Sorry I wasn't clear. This bug is specifically about the JM case. In JM this is not (safely) possible right now.
First, JM in summary if it's a JM bug.
Second, API compat: we have had JSOPTION_COMPILE_N_GO for a long time. I don't think we should drop it. We could make it a no-op, with JS_Compile* APIs all making unoptimized, maximally cacheable scripts, and JS_ExecuteScript calling the linker unconditionally. We'd want a separate API to call the linker for the case of executing more than once.
The requirement that every running script be tied to a particular global now solves problems for three independent efforts:
* JM wants to attach compiled machine-code that is specialized
for the global to the JSScript.
* jimb's new debugger work wants to keep a list of all the scripts
in each global, for UI purposes.
* Compartmental GC needs as many GC-references as possible to be
intra-compartment, including (1) the references from functions and
stack frames to scripts and (2) the references from scripts to
Should we file a separate bug for that?
Separate bug, I think -- this bug is really about eagerly compiling several scripts as they come in off the wire and before executing any of them, and making sure JM doesn't see that as violating the COMPILE_N_GO rules and run amok. That seems like a different issue.
Yeah. In my case, I only have one global involved for any given script.