This way we get the correct values for start-up prefs in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D51061
--HG--
extra : moz-landing-system : lando
Instead, this patch introduces a new `ObjLiteral` mini-bytecode format
that is used to carry object-literal information from parse time to a
later time at which GC objects are safe to allocate. The mini-bytecode simply
specifies a list of fields and constant field values.
The original intent of this patch (realized in previous versions of it)
was to make this an opcode, and completely replace object creation
sequences (NEWINIT, INITPROP, INITPROP, ...) with one OBJLITERAL opcode.
However, there are quite a few performance regressions that occur when
replacing the finely-tuned set of optimizations around this with a new
mechanism.
As a result, this patch only defers allocation of the objects until the
very end of parse. Each object literal adds an ObjLiteralCreationData
instance to the GC-things list, and when the GC-things list is processed
to perform deferred allocations, the described objects will be created.
Differential Revision: https://phabricator.services.mozilla.com/D47985
--HG--
extra : moz-landing-system : lando
Instead of checking for canonical function using scope chain, we can
directly use the functionOrGlobal field. By moving this to the
BaseScript class we can also simplify the debugger acccess.
Differential Revision: https://phabricator.services.mozilla.com/D47071
--HG--
extra : moz-landing-system : lando
To avoid calling JSScript::function() from finalizer, we need to read the
name earlier in process.
Differential Revision: https://phabricator.services.mozilla.com/D51474
--HG--
extra : moz-landing-system : lando
To allow InitScriptCoverage to be more flexible, we need to delay the call
until the JSScript is actually initialized. This moves the calls from
JSScript constructor until the JSScript is actually initialized. This is
similar to the debugger onNewScript call, but more cleanup would be needed to
unify these.
Differential Revision: https://phabricator.services.mozilla.com/D51473
--HG--
extra : moz-landing-system : lando
Set this flag for scripts that are for functions. This is equivalent to
checking the kind of the bodyScope() but is safe to call in GC contexts such
as finalization.
Also use an isFunction() accessor instead of checking if JSScript::function()
is nullptr throughout the codebase. Similarly, cleanup similar uses of
JSScript::module().
Differential Revision: https://phabricator.services.mozilla.com/D51472
--HG--
extra : moz-landing-system : lando
Instead, this patch introduces a new `ObjLiteral` mini-bytecode format
that is used to carry object-literal information from parse time to a
later time at which GC objects are safe to allocate. The mini-bytecode simply
specifies a list of fields and constant field values.
The original intent of this patch (realized in previous versions of it)
was to make this an opcode, and completely replace object creation
sequences (NEWINIT, INITPROP, INITPROP, ...) with one OBJLITERAL opcode.
However, there are quite a few performance regressions that occur when
replacing the finely-tuned set of optimizations around this with a new
mechanism.
As a result, this patch only defers allocation of the objects until the
very end of parse. Each object literal adds an ObjLiteralCreationData
instance to the GC-things list, and when the GC-things list is processed
to perform deferred allocations, the described objects will be created.
Differential Revision: https://phabricator.services.mozilla.com/D47985
--HG--
extra : moz-landing-system : lando
The code that uses these fields is part of a subsequent patch. This patch is just getting the tracing right.
Differential Revision: https://phabricator.services.mozilla.com/D48782
--HG--
extra : moz-landing-system : lando
Right now there BinAST is the only case, but subsequent patches will add GC pointers to XDR encoders and decoders.
Differential Revision: https://phabricator.services.mozilla.com/D48781
--HG--
extra : moz-landing-system : lando
JS_BIT and JS_BITMASK are only used in contexts where uint32_t is used, so these
two functions are now typed to accept and return uint32_t.
JS_HOWMANY and the three JS_ROUND functions are only used with size_t inputs,
so these four functions are now typed to accept and return size_t.
Differential Revision: https://phabricator.services.mozilla.com/D51142
--HG--
extra : moz-landing-system : lando
Both macros compute the same result, so we can replace ROUNDUP with JS_ROUNDUP.
Differential Revision: https://phabricator.services.mozilla.com/D51141
--HG--
extra : moz-landing-system : lando
When the `Debugger` API sets a breakpoint in a JSScript or wasm::Instance, the
BreakpointSite and Breakpoint objects belong to the code's compartment
(logically, at least - they're C++ objects and don't actually have any
compartment). Since a `Debugger` and its debuggees must be in separate
compartments, the Breakpoint's references to its owning `Debugger` and its
handler object must go through cross-compartment wrappers.
If we have nuked the `Debugger`'s compartment, it's not clear how we're still
trying to set breakpoints in its debuggees, but we should at least throw an
error, to capture a JavaScript stack when it occurs.
Differential Revision: https://phabricator.services.mozilla.com/D51210
--HG--
extra : moz-landing-system : lando
Use a single implementation in CacheIRCompiler.cpp for CacheIR emitters which
can be updated to the changed AutoCallVM class.
Differential Revision: https://phabricator.services.mozilla.com/D49922
--HG--
extra : moz-landing-system : lando
