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

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Boris Zbarsky [:bzbarsky]]

The use case is bug 521234.

Comment 1

[Brendan Eich [:brendan]]

It is possible already, see JSOPTION_COMPILE_N_GO.

/be

Comment 2

[Boris Zbarsky [:bzbarsky]]

Sorry I wasn't clear.  This bug is specifically about the JM case.  In JM this is not (safely) possible right now.

Comment 3

[Brendan Eich [:brendan]]

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

Comment 4

[Jason Orendorff [:jorendorff]]

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?

Comment 5

[Jason Orendorff [:jorendorff]]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Yeah.  In my case, I only have one global involved for any given script.