Debugger::onSingleStep asserts that the script's step mode count is fully
accounted for by Debugger.Frame instances with onStep handlers. The existing
assertion only takes into account live Debugger.Frames --- it simply looks up
the current frame's AbstractFramePtr in existing Debuggers' frame maps. But
Debugger.Frames referring to suspended generator calls also contribute to the
generator's script's step mode count, and need to be included.
Differential Revision: https://phabricator.services.mozilla.com/D27846
--HG--
extra : moz-landing-system : lando
Similar to AutoSetGeneratorRunning, AdjustGeneratorResumptionValue also needs to modify the
async-generator state in addition to the shared generator state.
Differential Revision: https://phabricator.services.mozilla.com/D30035
--HG--
extra : moz-landing-system : lando
The generator 'closing' state, indicated by the value RESUME_INDEX_CLOSING in an
AbstractGeneratorObject's RESUME_INDEX_SLOT is never distinguished from the
'running' state, so RESUME_INDEX_CLOSING, and its associated setters and
predicates, can be removed.
RESUME_INDEX_RUNNING remains as a magic value appearing in the resume index
slot, and is now used as an upper bound on normal resume index values instead of
RESUME_INDEX_CLOSING.
Differential Revision: https://phabricator.services.mozilla.com/D29391
--HG--
extra : moz-landing-system : lando
This patch further centralizes builtin signature information into
SymbolicAddressSignature, removing more than 100 lines of code
and preparing the way for the next patch, which will use this
eager error check to return a JSObject* from Instance::tableGet.
Differential Revision: https://phabricator.services.mozilla.com/D29595
--HG--
extra : rebase_source : cea08b16b0caca43ae983584faf39fc020606e71
extra : histedit_source : 72b5da9c3c905f43a0caedbf842b9f950532b473
This patch further centralizes builtin signature information into
SymbolicAddressSignature, removing more than 100 lines of code
and preparing the way for the next patch, which will use this
eager error check to return a JSObject* from Instance::tableGet.
Differential Revision: https://phabricator.services.mozilla.com/D29595
--HG--
extra : rebase_source : 64487029305c1d50c3d525509130a7992e3167b0
wasmTextToBinary allows a naked type name, but standard wat
syntax requires (result t) for ifs and blocks. Supporting
this in wasmTextToBinary makes it easier to share wasm
source code among the tools.
Differential Revision: https://phabricator.services.mozilla.com/D30098
--HG--
extra : moz-landing-system : lando
This patch enables CacheIR call ICs by default, and turns off the old call ICs when CacheIR ICs are turned on.
Differential Revision: https://phabricator.services.mozilla.com/D29537
--HG--
extra : moz-landing-system : lando
Bug 1548510 part 2 moved some code into this file without including the
header for SprintfLiteral.
Differential Revision: https://phabricator.services.mozilla.com/D30062
--HG--
extra : moz-landing-system : lando
TokenStream.cpp:
- Allow '_' between digits per the proposal.
- It's a SyntaxError if '_' is not followed by another digit.
- It's also a SyntaxError if '_' is not preceded by a digit, e.g. |1._1|.
- '_' is not allowed in legacy octal literals and (the integer part of) noctal
literals (|07_1| and |09_1| are disallowed, but |09.1_2| is allowed).
jsnum.{h,cpp}:
- Add an option to GetPrefixInteger(...) to ignore '_' in numbers when called
from TokenStream.
- Add GetDecimalNonInteger(...) as the counterpart of GetDecimalInteger(...)
which parses non-integer decimals. Adding a new function is simpler than
modifying js_strtod to conditionally ignore '_' in this case.
- GetDecimalInteger(...) and GetDecimalNonInteger(...) are only called from
TokenStream, so both functions always ignore '_'.
- ComputeAccurateDecimalInteger(...) and ComputeAccurateBinaryBaseInteger(...)
both now ignore '_'. This is correct even when called from GetPrefixInteger(...)
with |IntegerSeparatorHandling::None|, because GetPrefixInteger(...) already
selects the parseable integer prefix.
Differential Revision: https://phabricator.services.mozilla.com/D28531
--HG--
extra : moz-landing-system : lando
Changes for legacy octal and noctal literal parsing are in preparation for the
next part.
Differential Revision: https://phabricator.services.mozilla.com/D28530
--HG--
extra : moz-landing-system : lando
Rather than consulting the debugger weak maps to add reverse edges corresponding to forward edges added for cross compartment wrappers, add both forward and reverse edges when iterating the cross compartment wrapper map. Remove zone counts from debugger weak maps.
Differential Revision: https://phabricator.services.mozilla.com/D29496
--HG--
extra : moz-landing-system : lando
1. In bug 1545278, Ted is making our story about guarding on object pointer identity more robust. Since I am adding a new guardSpecificObject call in the ConstStringSplit patch, it seemed reasonable to add guardSpecificFunction now instead of later.
2. It's not directly relevant in the current patch, but in a previous version of the StringSplit patch (before I realized we could delete the whole thing) it turned out that calling isSelfHostedFunctionWithName on an arbitrary function can trigger assertions, because GetSelfHostedFunctionName assumes isExtended, but isSelfHostedBuiltin does not necessarily imply isExtended (in the case of nested anonymous functions).
3. Fixing the format string in a JitSpew message I added in a previous stack.
Depends on D29535
Differential Revision: https://phabricator.services.mozilla.com/D29536
--HG--
extra : moz-landing-system : lando
I started changing StringSplit to attach outside of self-hosted code, to match ConstStringSplit. Upon closer examination, the StringSplit IC doesn't actually add any value, and we're better off deleting it. The generated code calls StringSplitHelper, which ends up doing almost exactly the same thing as the call to intrinsic_StringSplitString it replaces. When we first wrote the patch (bug 1366377), the advantage was that we got to skip a lookup to determine the group of the resulting object. However, a subsequent patch created a single group for every StringSplitString result, which is basically free to look up.
I couldn't write a microbenchmark where the StringSplit IC made any difference, so let's just delete it and simplify our codebase.
Depends on D29534
Differential Revision: https://phabricator.services.mozilla.com/D29535
--HG--
extra : moz-landing-system : lando
Some native functions (for example, the Array constructor) have constructor-like behaviour even when called in a non-constructing context. We still want to create template objects for these cases. This fixes a noticeable regression in Speedometer (particularly in EmberJS-debug).
Depends on D29533
Differential Revision: https://phabricator.services.mozilla.com/D29534
--HG--
extra : moz-landing-system : lando
While trying to pin down a performance regression, I realized that both the new and the old implementations of ConstStringSplit are broken. Three years ago, as part of some ES6 work, we changed String.prototype.split to call a self-hosted String_split function instead of native str_split. In turn, String_split calls intrinsic_StringSplitString in the case we care about. However, because the call to intrinsic_StringSplitString is in self-hosted code, we would only get value out of this stub if there was only one caller of String_split in the entire program.
This patch changes ConstStringSplit to look for the self-hosted String_Split function, which means we can attach a stub to the user script instead of self-hosted code. It also adds support in BaselineInspector for extracting metadata about the string split from the stub, which enables the Ion version of this optimization.
Depends on D29532
Differential Revision: https://phabricator.services.mozilla.com/D29533
--HG--
extra : moz-landing-system : lando
When pushing arguments for a JIT call, we push the callee value onto the stack, and then immediately pop it off. This is a remnant of the old implementation.
This patch removes that wart, with a small detour to rewrite/recomment alignJitStackBasedOnNArgs for clarity.
Differential Revision: https://phabricator.services.mozilla.com/D29532
--HG--
extra : moz-landing-system : lando
These tests need to be disabled to get a green run on the Android x86_64
test platform. The failures in toolkit/components/extensions are
concerning and definitely require follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D29843
--HG--
extra : moz-landing-system : lando
Marking GetGlobalJSObject and GetGlobalJSObjectPreserveColor final and inline
on inner/outer windows allows compilers to de-virtualize and inline them, which
makes them just as fast as calling FastGetGlobalJSObject is now (in the case of
GetGlobalJSObjectPreserveColor; GetGlobalJSObject has to do the gray-unmarking,
which is a bit more work).
In WindowDestroyedEvent::Run we want to switch to GetGlobalJSObject(), because
we want to root the object and hence should unmark gray.
In nsGlobalWindowInner::RunTimeoutHandler we likewise want to unmark gray. The
AutoEntryScript constructor likely did that already, but it's not that
expensive when it doesn't need to do any work.
Differential Revision: https://phabricator.services.mozilla.com/D29711
--HG--
extra : moz-landing-system : lando
Consumers that just care about this boolean state should use this instead of
getting the JSObject* directly.
Differential Revision: https://phabricator.services.mozilla.com/D29705
--HG--
extra : moz-landing-system : lando
This can be used in things like assertions or some other rare circumstances
where not exposing the object to active JS is OK.
Differential Revision: https://phabricator.services.mozilla.com/D29704
--HG--
extra : moz-landing-system : lando
This lock was necessary when the JITs used these strings (off-thread Ion compilation),
but now the lock was just adding overhead to each script we finalize etc.
This replaces ExclusiveData<> with MainThreadData<> to assert on-main-thread in debug
builds.
Differential Revision: https://phabricator.services.mozilla.com/D29798
--HG--
extra : moz-landing-system : lando
Ion does not compile the catch block so the analysis fails to account for code
there.
Differential Revision: https://phabricator.services.mozilla.com/D29475
--HG--
extra : moz-landing-system : lando
I considered adding BaselineInterpreter.{h,cpp} files but there are shared
helper functions so this might get awkward. Maybe once the rest of the code is
in we can experiment with changes in this area.
Differential Revision: https://phabricator.services.mozilla.com/D29158
--HG--
extra : moz-landing-system : lando
Differential Revision: https://phabricator.services.mozilla.com/D28724
***
Bug 1546138 - Baldr: remove (ref T) special case from Val union (r=lth)
Differential Revision: https://phabricator.services.mozilla.com/D29298
--HG--
extra : rebase_source : 1495303130eaf5e81e0222276ec628c6765c2e24
extra : histedit_source : baa9e0b47d5f2f05778a5bde3232df1bdbdd3408%2Cbf572fbe0950726a3dd119d17f2caa8150bf1bb3
This trampoline isn't performance sensitive so platform-specific optimizations
are not worth it.
Differential Revision: https://phabricator.services.mozilla.com/D28601
--HG--
extra : moz-landing-system : lando
This patch further centralizes builtin signature information into
SymbolicAddressSignature, removing more than 100 lines of code
and preparing the way for the next patch, which will use this
eager error check to return a JSObject* from Instance::tableGet.
Differential Revision: https://phabricator.services.mozilla.com/D29595
--HG--
extra : rebase_source : d2c7f27b80ebe3c0884845b471c3de61c0979047
In D25705, I added a new arenaId member to the js::BaseAllocPolicy. This
increased the size of everything that uses a JS AllocPolicy, which is a
lot.
This change follows suit from earlier work, which is to make everything
allocation-related have an "arena" version and a "default" version that
uses the arena version with the implied default arena.
StringBuffer is then changed to use this new functionity to define its
own alloc policy that uses the new StringBufferArena.
Differential Revision: https://phabricator.services.mozilla.com/D29685
--HG--
extra : moz-landing-system : lando
This was incorrectly implemented in bug 1542448 - for a class without a
name, the .initializers varaible would correctly use the class scope,
but would incorrectly use the tdzCache of the *surrounding* scope.
Having two distinct .initializer variables use the same tdzCache caused
the crash in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D29574
--HG--
extra : moz-landing-system : lando
The Baseline Interpreter will use incrementNumDebuggeeRealms and
decrementNumDebuggeeRealms to toggle some debugging things if needed.
Differential Revision: https://phabricator.services.mozilla.com/D28636
--HG--
extra : moz-landing-system : lando
This patch passes a message through the HangMonitor channel when navigating
through history to cancel content JS that could hang the chrome JS in the
content process responsible for history navigation. If the content JS is
actually canceled, this also disables the BF cache for the current page, since
it could end up in an inconsistent state due to the JS cancellation.
Differential Revision: https://phabricator.services.mozilla.com/D23089
--HG--
extra : moz-landing-system : lando
Bug 1052579 introduced a new mozjemalloc arena for JSString char buffers.
Unfortunately, my testing missed the case where JSStringBuilder causes an OOM
condition, causing the OOM handler to realloc to the default arena, regardless
of what arena is actually indicated by the AllocPolicy for the char vector.
The realloc now passes the arena from the AllocPolicy to mozjemalloc.
Differential Revision: https://phabricator.services.mozilla.com/D29092
--HG--
extra : moz-landing-system : lando
I removed WeakRef since this is already very close to WeakHeapPtr and is an alias of it. I think having the two is more confusing than using the same name for both (the difference is whether you trace it with TraceWeakEdge or sweep it in a more manual fashion).
Differential Revision: https://phabricator.services.mozilla.com/D29180
Differential Revision: https://phabricator.services.mozilla.com/D29337
The Context 0.1 format specifies that the (de)compression of nodes is determined by:
- its node type;
- its parent type;
- the index in the parent node;
- whether the node is an element of an array.
This patch modifies the parser generator to pass the information during parsing.
Differential Revision: https://phabricator.services.mozilla.com/D28534
--HG--
extra : moz-landing-system : lando
We had a script size limit (and number of locals/args limit) when off-thread Ion
compilation wasn't available, but no hard limit when off-thread compilation is
available. This patch addresses that.
This patch also converts the main-thread limits from constants to JitOptions
because that's what we use for new code.
Differential Revision: https://phabricator.services.mozilla.com/D29217
--HG--
extra : moz-landing-system : lando
Our Wasm implementations current reject data.drop and elem.drop if there is no
memory or table in the module. This isn't consistent with the current
bulk-memory specification, though.
See https://github.com/WebAssembly/bulk-memory-operations/issues/79.
This patch fixes that by slightly loosening the relevant checks, so as to
allow a segment to be dropped even if there is no memory, providing that that
segment is a passive one.
Most of the changes are in the test file passive-segs-nonboundary.js:
* There are four new checks for data.drop without memory and the equivalents
for table.drop.
* Test construction function `do_test` has been made more flexible, so it is
now possible to independently specify whether a table/memory is present,
whether active initialisers are present, and whether passive initialisers
are present.
In WasmModule.cpp, a couple of places where a segment vector was asserted to
be empty have been changed to assert that it contains only passive segments.
Attempts to do this using std::all_of and a closure were unsuccessful (see bug
1547031) and instead a debug-only helper function `AllSegmentsArePassive` was
added.
Differential Revision: https://phabricator.services.mozilla.com/D28951
--HG--
extra : rebase_source : 2f85bf4fb32a424098ba24670790adee917f882f
Add a gc() call so that any in-progress GC triggered by creating objects gets finished up and the test starts from a known state.
I also updated the binjs compiled versions of this test.
Differential Revision: https://phabricator.services.mozilla.com/D28699
An AbstractGeneratorObject's RESUME_INDEX_SLOT indicates the state of the
generator object: it may be `undefined` (before initial yield), `null` (closed),
or an integer (running, closing, or suspended).
AbstractGeneratorObject has a number of predicate methods to test for these
various states. Unfortunately, some of the predicates grab RESUME_INDEX_SLOT and
immediately call `toInt32` on its value, which crashes if it is not an Int32.
This means the only safe way to ask if an AbstractGeneratorObject is suspended
is:
!isBeforeInitialYield() && !isClosed() && isSuspended()
If either of the first two conditions is true, isSuspended will assert. This is
verbose, and means the predicates cannot be used without studying the details of
the RESUME_INDEX_SLOT's representation.
This patch makes the predicates assertion-free. isSuspended acquires a new
branch, but the others should be just as efficient as they were before.
Differential Revision: https://phabricator.services.mozilla.com/D27941
--HG--
extra : moz-landing-system : lando
Because SharedScriptData now contains numICEntries, we can allocate the ICScript
up front and fill it in directly. Advantages are: no Vector malloc/free overhead,
no ICEntry copying, no more LifoAlloc::steal, better cache locality, fewer moving
parts. This also makes it easier to merge ICScript and TypeScript in the future.
Differential Revision: https://phabricator.services.mozilla.com/D28451
--HG--
extra : moz-landing-system : lando
This also tidies up overflow checks to ensure numICEntries never overflows
UINT32_MAX in the emitter.
ICScript currently stores numICEntries as uint32_t, but it's not an
issue due to BaselineMaxScriptLength.
Differential Revision: https://phabricator.services.mozilla.com/D28450
--HG--
extra : moz-landing-system : lando
This makes the naming more consistent. Also, instead of checking against
JSScript::MaxBytecodeTypeSets at every JOF_TYPESET op, we can move this
condition to SharedScriptData creation if we use uint32_t instead of uint16_t.
This is more efficient and also nicer because MaxBytecodeTypeSets seems to be
more of a JSScript implementation detail the bytecode emitter doesn't need to
worry about.
Differential Revision: https://phabricator.services.mozilla.com/D28449
--HG--
extra : moz-landing-system : lando
This is the other patch with non-trivial refactoring. (GetPropIRGenerator was the first.)
Differential Revision: https://phabricator.services.mozilla.com/D27312
--HG--
extra : moz-landing-system : lando
This was the last consumer of the old implementation of TryAttachStub/TryAttachIonStub. This patch removes the transitional version.
Differential Revision: https://phabricator.services.mozilla.com/D27310
--HG--
extra : moz-landing-system : lando