HandleDebugTrap calls DebugAfterYield, which can call the onEnterFrame debugger hook.
This hook can mess with debugger state so HandleDebugTrap needs to be a bit more
careful with its assertions.
Differential Revision: https://phabricator.services.mozilla.com/D36209
--HG--
extra : moz-landing-system : lando
Merge Debugger::addGeneratorFrame into DebuggerFrame::setGenerator, and expand
the role of clearGenerator to fully undo the effect of setGenerator.
The association between a Debugger.Frame referring to a generator or async call
and the underlying generator object must be recorded in five separate places, as
a transaction: either all or present, or none are present. To ensure this is
true, this patch places sole responsibility for emplacing all those relations in
a single function (setGenerator), with another function to tear down those
relations (clearGenerator) as its inverse/antidote/complement/antagonist (in the
anatomical sense)/what-have-you.
Actually, when a Debugger.Frame is GC'd, we cannot reliably undo some of the
connections, and in fact can let the GC take care of those for us, so the
tear-down function clearGenerator is split into two overloads, one which is
suitable for use from a finalizer and the other which takes care of the entire
task.
Differential Revision: https://phabricator.services.mozilla.com/D35607
--HG--
extra : moz-landing-system : lando
Later in this patch series, we will be gathering up all the code to manage the
association between DebuggerFrame and AbstractGeneratorFrame objects into a pair
of functions, one to establish a relation and the other to tear it down. The
removeif method combines iteration and entry removal, but we would rather have
entry removal live next to the code that tears down the rest of the association.
In preparation for that, this changeset replaces the sole use of removeIf with
its (not very large) definition, so that the entry removal can be more readily
moved into another function.
Differential Revision: https://phabricator.services.mozilla.com/D35606
--HG--
extra : moz-landing-system : lando
Without this patch, addGeneratorFrame may be called from any realm, and enters
the debugger's realm to call DebuggerFrame::setGenerator. However, we would like
to merge addGeneratorFrame and setGenerator, and call the combined from various
points which are already in the debugger's realm, so it would be a little nicer
to simply make the function assume it is called from the debugger's realm.
Differential Revision: https://phabricator.services.mozilla.com/D35605
--HG--
extra : moz-landing-system : lando
The hand-written assembly for libffi on aarch64/windows doesn't emit
unwind information. If we ever tried to unwind through these functions,
they'd look like leaf functions, which is decidedly not true and would
cause great pain.
For whatever reason, the original aarch64 libffi functions used
x21/x22/x23/x24 as their (callee-saved) scratch registers. This
convention works on windows as well, but the unwind information on
windows mandates that we start saving callee-saved registers starting
from x19, rather than x21. Rather than rewriting the assembly to use
x19/x20 instead of x21/x22, which would be a large change, we chose
instead to simply save/restore extra registers in the prolog/epilog.
This change does make the stack frame sizes slightly bigger, but an
extra 16 bytes in libffi stack frames should not matter.
The `-TC` change is necessary to make the compiler play nicely with .asm
file suffixes.
Differential Revision: https://phabricator.services.mozilla.com/D35714
--HG--
extra : moz-landing-system : lando
If optional arrays of SharedScriptData are empty, avoid storing their
offset in order to save memory. This is done by deduplicating offsets
and storing this variably-sized set of offsets as a trailing array. A
uint32_t for each non-empty array. These offsets are analogous to the
array length we would naively consider storing but with careful encoding
for performance.
Differential Revision: https://phabricator.services.mozilla.com/D34791
--HG--
extra : moz-landing-system : lando
Add a flag into the byte array area. It is inserted before code() so it
will be at a fixed offset once atoms are removed. This will be used to
store flags about optional trailing arrays.
Differential Revision: https://phabricator.services.mozilla.com/D34789
--HG--
extra : moz-landing-system : lando
Now that PrivateScriptData contains a single array, the PackedSpan
mechanism for packing multiple trailing arrays can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D35817
--HG--
extra : moz-landing-system : lando
These arrays contain only relocatable, cloneable data and should be made
shareable. The API they now expose in SharedScriptData uses Span.
Differential Revision: https://phabricator.services.mozilla.com/D34790
--HG--
extra : moz-landing-system : lando
Pad the source notes with SRC_NULL such that the code and notes arrays
together maintain uint32_t alignment. This is will later be used to add
optional trailing arrays with uint32_t alignment. The allocator would
already be rounding up our allocation so actually memory usage should be
neutral.
Differential Revision: https://phabricator.services.mozilla.com/D34788
--HG--
extra : moz-landing-system : lando
Make access to trailing arrays more consistent with other data
structures and better encapsulate the reinterpret_casts.
Differential Revision: https://phabricator.services.mozilla.com/D34787
--HG--
extra : moz-landing-system : lando
As PrivateScriptData contains less data, we need to make this test have
more complicated functions so that the test is not sensistive to
allocator rounding. This also removes the binjs variant of test until
they next time they are regenerated.
Differential Revision: https://phabricator.services.mozilla.com/D35840
--HG--
extra : moz-landing-system : lando
Gary noticed we can't build without NSPR on Windows due to this unused #include
inside #ifdef XP_WIN. This patch fixes the build.
Differential Revision: https://phabricator.services.mozilla.com/D35494
--HG--
extra : moz-landing-system : lando
Merge Debugger::addGeneratorFrame into DebuggerFrame::setGenerator, and expand
the role of clearGenerator to fully undo the effect of setGenerator.
The association between a Debugger.Frame referring to a generator or async call
and the underlying generator object must be recorded in five separate places, as
a transaction: either all or present, or none are present. To ensure this is
true, this patch places sole responsibility for emplacing all those relations in
a single function (setGenerator), with another function to tear down those
relations (clearGenerator) as its inverse/antidote/complement/antagonist (in the
anatomical sense)/what-have-you.
Actually, when a Debugger.Frame is GC'd, we cannot reliably undo some of the
connections, and in fact can let the GC take care of those for us, so the
tear-down function clearGenerator is split into two overloads, one which is
suitable for use from a finalizer and the other which takes care of the entire
task.
Differential Revision: https://phabricator.services.mozilla.com/D35607
--HG--
extra : moz-landing-system : lando
Later in this patch series, we will be gathering up all the code to manage the
association between DebuggerFrame and AbstractGeneratorFrame objects into a pair
of functions, one to establish a relation and the other to tear it down. The
removeif method combines iteration and entry removal, but we would rather have
entry removal live next to the code that tears down the rest of the association.
In preparation for that, this changeset replaces the sole use of removeIf with
its (not very large) definition, so that the entry removal can be more readily
moved into another function.
Differential Revision: https://phabricator.services.mozilla.com/D35606
--HG--
extra : moz-landing-system : lando
Without this patch, addGeneratorFrame may be called from any realm, and enters
the debugger's realm to call DebuggerFrame::setGenerator. However, we would like
to merge addGeneratorFrame and setGenerator, and call the combined from various
points which are already in the debugger's realm, so it would be a little nicer
to simply make the function assume it is called from the debugger's realm.
Differential Revision: https://phabricator.services.mozilla.com/D35605
--HG--
extra : moz-landing-system : lando
Update the memory pressure observers for main thread and workers to call the new JS API to set/clear the low memory state.
Differential Revision: https://phabricator.services.mozilla.com/D35682
Add a lowMemoryState field to GCRuntime and an API set set it. Use it to restict the nursery size when resizing the nursery.
Differential Revision: https://phabricator.services.mozilla.com/D35680
This adds tracking of malloc memory to WasmInstanceObject, WasmGlobalObject, WasmMemoryObject and ResolveResponseClosure (the straightforward cases).
Differential Revision: https://phabricator.services.mozilla.com/D35485
