The default bug view has changed. See this FAQ.

JM: Consider making it possible to COMPILE_N_GO compile scripts and then run them at a later time

RESOLVED WONTFIX

Status

()

Core
JavaScript Engine
RESOLVED WONTFIX
7 years ago
4 years ago

People

(Reporter: bz, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

The use case is bug 521234.
No longer blocks: 521234
Blocks: 521234
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
Summary: Consider making it possible to COMPILE_N_GO compile scripts and then run them at a later time → JM: Consider making it possible to COMPILE_N_GO compile scripts and then run them at a later time
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.

Updated

4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.