We collect the nursery in idle time if there is less than 256KB of space
remaining. However when the nursery is small this doesn't make sense, so
add a percentage-based threshold to be used when the nursery is small.
Differential Revision: https://phabricator.services.mozilla.com/D20247
--HG--
extra : moz-landing-system : lando
This clarifies the descriptions of newCompartment, sameCompartmentAs, and
sameZoneAs.
Differential Revision: https://phabricator.services.mozilla.com/D20910
--HG--
extra : moz-landing-system : lando
I initially set this to 64K thinking that it'd prevent too much changing of
the nursery size and therefore (once implemented) too many calls to
madvise. But that's not true, because the nursery only changes size when a
tenure rate threshold is hit, and once it does it always changes size. So
we can reduce this to 4K for simplicity and alignment with other constants.
Differential Revision: https://phabricator.services.mozilla.com/D21157
--HG--
extra : moz-landing-system : lando
This works around the issue where if the PC and SP don't change while unwinding our JIT frame, we'll fail the unwinder's sanity checks and it won't call our exception handler.
Ideally we'd store proper unwind info, but that's a larger change for another day.
Differential Revision: https://phabricator.services.mozilla.com/D20858
--HG--
extra : moz-landing-system : lando
- Ensure that HasBeenCloned flag is set on LazyScript when setting it on
JSScript so it is preserved by relazification.
- Never preserve HasBeenCloned flag in LazyScript XDR.
NOTE: With the first fix, this is not needed for tests to pass anymore.
- Add a LazyScript::packedFieldsForXDR() helper to strip out runtime
flags before serializing.
Depends on D21069
Differential Revision: https://phabricator.services.mozilla.com/D21070
--HG--
extra : moz-landing-system : lando
This brings LazyScript behaviour of this flag in sync with JSScript and
the split between ImmutableFlags and MutableFlags.
Differential Revision: https://phabricator.services.mozilla.com/D21069
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
Also replace a few packed bitfields with normal fields since this is a
stack type only.
Differential Revision: https://phabricator.services.mozilla.com/D20886
--HG--
extra : moz-landing-system : lando
Both BinASTParserBase.{lazyScript_,handler_} are not used in BinASTParserBase,
but in BinASTParserPerTokenizer.
Moved them to BinASTParserPerTokenizer.
Differential Revision: https://phabricator.services.mozilla.com/D20775
--HG--
extra : moz-landing-system : lando
BinASTParserBase::allocParseNode was used only for creating
ParseNodeKind::ParamsBody node, and other nodes are created by FullParseHandler.
Added FullParseHandler::newParamsBody and removed ParseNode allocation
methods from BinASTParserBase.
Differential Revision: https://phabricator.services.mozilla.com/D20774
--HG--
extra : moz-landing-system : lando
The watchdog thread's stack is intentionally kept as small as possible, since
the work that it does is trivial and should not require much stack space.
One result of this is that the stack segment is generally too small to
instantiate a new service (and we really don't want to be instantiating
services on it anyway).
The debug service is generally instantiated before the watchdog thread tries
to touch it, but this isn't guaranteed (and, in particular, it often isn't for
xpcshell runs on some noopt debug builds). Instantiating it before starting
the watchdog thread solves this problem.
Differential Revision: https://phabricator.services.mozilla.com/D20869
--HG--
extra : rebase_source : 2f9c3e412a7ad9a0b6f84c61907e4a7508f3b18c
Add support to WasmIonCompile for the instructions in the reftypes
proposal: ref.null, ref.is_null, table.get, table.set, table.grow,
table.size.
Also add support for the ref.eq instruction from the gc proposal.
Also update the test suite so that we will not ion-compile test cases
that use gc features that are not landed here.
Note that this patch does not change the compiler-selection behavior:
If --wasm-gc is enabled then only the baseline compiler will be used;
if --wasm-gc is not enabled then no compiler will recognize these
opcodes. Enabling Ion for reftypes content is the subject of
subsequent work.
Differential Revision: https://phabricator.services.mozilla.com/D20519
--HG--
extra : rebase_source : 0048acdd0235b231f74f51630826f0690340bc3b
Thanks to Bruno Keith & Niklas Baumstark from the phoenhex team for finding this
issue and reporting it with a proper analysis.
Differential Revision: https://phabricator.services.mozilla.com/D20343
MacroAssembler::wasmReserveStackChecked takes a parameter |amount|, which
appears to be the number of bytes pushed by the prologue, not including for
the wasm::Frame, up to this point. If this value is zero, the stack overflow
check is omitted.
I believe this logic is incorrect and that the stack overflow check should
never be omitted. There's no way any non-leaf call could really use zero
bytes of stack in total, since there would be no place to store the return
address.
I believe this code worked by accident, for the following reason: |amount| is
never zero. That happens because, currently, wasm::Frame is 3 words (except
on ARM64). That's 12 bytes or 24 bytes, depending on word size. At some
point I imagine that |amount| is rounded upwards, prior to the call to
MacroAssembler::wasmReserveStackChecked, so that |amount| +
sizeof(wasm::Frame) is 0 % 16.
If amount was originally zero, then it will be adjusted upwards to 4 (16-12)
on a 32-bit system and to 8 (32-24) on a 64-bit system. The end effect is
that |amount| can never be zero here.
The fix is simply to remove the early exit.
The AutoDebuggerJobQueueInterruption destructor asserts that the Debugger has
properly managed its hooks' asynchronous jobs. But this assertion clearly only
applies when the AutoDebuggerJobQueueInterruption is properly initialized;
otherwise, the debuggee's job queue is still in place.
Unfortunately, the destructor was using the wrong test to determine whether the
debuggee's queue had been saved. This patch makes it uses the `initialized`
method, rather that checking the `cx` field, which is always initialized.
Differential Revision: https://phabricator.services.mozilla.com/D20575
--HG--
extra : moz-landing-system : lando
ZoneCellIter can return cells that are about to be finalised in the next GC
slice. These cells can be used briefly but cannot be kept around and the GC
needs this behaviour.
This change introduces ZoneCellIterSafe which will not return about-to-be
finalised cells. Zone::cellIter() will use it now, the old behaviour is now
in cellIterUnsafe().
Update several uses of cellIter() to cellIterUnsafe() where that behaviour
is needed.
Differential Revision: https://phabricator.services.mozilla.com/D19890
--HG--
extra : moz-landing-system : lando
A few instances of snprintf are replaced with SprintfLiteral, and a
implicit constructor is made explicit.
Differential Revision: https://phabricator.services.mozilla.com/D20401
--HG--
extra : moz-landing-system : lando
This position ends up being used for source notes in some cases now, meaning that this can
cause breakpoints to be given the wrong position when assigned to a variable. This fixes
that by using the correct token for the position value.
This fix also ensures that `cur->pos.end` is updated when skipping functions because
expression statements set their end based on the end position of the expression, and
if the expression statements end token is the end of a skipped function, we would
otherwise read the wrong position triggering assertion failures.
Differential Revision: https://phabricator.services.mozilla.com/D19714
--HG--
extra : moz-landing-system : lando
Currently, some of the JS allocators accept an 'arena' argument, but some
don't. This change makes it so they all do. This is nice for consistency, but
it also feeds into Bug 1052579, which will need to use arenas for JSString
backing buffers.
Differential Revision: https://phabricator.services.mozilla.com/D19717
--HG--
extra : moz-landing-system : lando
BasicDllServices is used to gain access to the authenticode APIs in non-Gecko
contexts. One feature that WinDllServices provides is the ability to register
a callback interface to be notified when a DLL has been loaded.
This is not particularly useful in the BasicDllServices use case, and in the
"handle a launcher process failure on a background thread" use case, would
actually be harmful.
This patch modifies the DLLServices backend to offer a "basic" option that
omits the callback stuff.
Differential Revision: https://phabricator.services.mozilla.com/D19696
--HG--
extra : moz-landing-system : lando
This may lose some tiny amount of performance since the existing code
duplicated a huge amount of code in order to avoid walking bits of the tree
that can't contain functions. I preserved a few of those hacks but some of the
bits seemed too small to bother with.
The expression `nparents_ - 1` is changed to `nparents_ - 2` because, as a
result of how ParseNodeVisitor control flow works, we now call gatherNameable
*after* pushing the current FunctionNode to the stack, rather than before.
(A new assertion checks that this is the case.)
Differential Revision: https://phabricator.services.mozilla.com/D20720
--HG--
extra : moz-landing-system : lando
This is meant as a sanity patch. Before, buf_ was a pointer to a local
variable, set in resolveFun() and just left dangling on exit. No bug, but
dangling pointers are bad.
I considered removing buf_ and passing around a reference to the local
StringBuffer, but this was quicker and seemed easier to review.
Differential Revision: https://phabricator.services.mozilla.com/D20719
--HG--
extra : moz-landing-system : lando
The `Expr` suffix is for nodes that can appear anywhere an expression could
appear. This kind of node can't; it's always the direct child of a tagged
template.
Differential Revision: https://phabricator.services.mozilla.com/D20717
--HG--
extra : moz-landing-system : lando
I tried making ParseNodeVisitor take all nodes as references, but that didn't
work nicely with the existing accept() method templates. That could have been
made to work using more template tricks, but I decided pointers are not so bad.
There still was no way to avoid the code duplication here without contortions.
Differential Revision: https://phabricator.services.mozilla.com/D20716
--HG--
extra : moz-landing-system : lando
Some functionality is intentionally unimplemented to make this patch
smaller and at a faster cadence: field initializers are stored on
this['.initializers'] instead of a local, derived classes are not
supported yet, and constant-folding/inline field initializers are not
implemented.
Differential Revision: https://phabricator.services.mozilla.com/D16343
--HG--
extra : moz-landing-system : lando
The wasm baseline and via-Ion compilers both generate numerous calls to
supporting functions ("instance functions"). To generate correct code, and,
shortly, correct stackmaps too, the compilers need to know argument and return
types for these functions. Currently that information is scattered around
somewhat:
* In baseline, emitInstanceCall() specifies both arg and return types
* In via-Ion, builtinInstanceMethodCall specifies the return type. Arg types
aren't (obviously) available, but will be needed for upcoming stack map
generation.
This bug makes the following main changes:
* Adds a new type, SymbolicAddressSignature, related to the existing
SymbolicAddress type. A SymbolicAddressSignature specifies the arity,
argument and return types for a SymbolicAddress.
* For all the SymbolicAddresses referred to in the baseline and via-Ion
compilers, a static SymbolicAddressSignature is provided, as readonly data.
* The compilers then pass around |const SymbolicAddressSignature&| where
before they just passed around a SymbolicAddress, to the extent possible.
* All ad-hoc specification of arg and return types in emitInstanceCall()
[baseline] and builtinInstanceMethodCall() [via Ion] have been removed.
* Not all SymbolicAddress values have an associated SymbolicAddressSignature
-- only those referred to in calls to emitInstanceCall() and
builtinInstanceMethodCall() do.
Smaller changes:
* WasmBaselineCompile.cpp:
- removed MIRTypeVector and SigP*_.
- pushReturnValueOfCall: overloaded so as to accept both ExprType and MIRType.
- emitInstanceCall now accepts a |const SymbolicAddressSignature&| and pulls
type info out of that. All uses changed accordingly.
- [drive-by fix]: emitInstanceCall: added a comment update that should have
been in bug 1528240 ("Fix inconsistent return type use in
BaseCompiler::emitInstanceCall")
* WasmIonCompile.cpp:
- passArg: overloaded so as to accept both MIRType and ValType for the node
type
- builtinInstanceMethodCall now accepts a |const SymbolicAddressSignature&|
and pulls type info out of that. All uses changed accordingly.
* WasmBuiltins.{cpp, h}: add the static SymbolicAddressSignature bundles.
* WasmGC.h: add an overload of StackArgAreaSizeUnaligned that can take a
Symbolic AddressSignature directly.
--HG--
extra : rebase_source : 00909db26977288401c708dfc73175c6f1882b3d