The use case is bug 521234.
7 years ago
It is possible already, see JSOPTION_COMPILE_N_GO. /be
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. Jason, thoughts? /be
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 internal objects. 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.