Add a new class to extract tracelogger data using chunked buffers and use this to write the data out to the profiler JSON output. Copying the data in chunks lets us minimize our memory overhead when writing out to the profiler so a large array of millions of elements does not need to be allocated ahead of time.
Differential Revision: https://phabricator.services.mozilla.com/D11791
--HG--
extra : moz-landing-system : lando
We now emit JSOP_CALLEE or JSOP_ENVCALLEE (a new op) to load the callee.
JSOP_SUPERFUN and JSOP_SUPERBASE no longer have to walk the scope/environment
chain.
Differential Revision: https://phabricator.services.mozilla.com/D13688
--HG--
extra : moz-landing-system : lando
This was added in bug 833076 because back then TypeScript::SetThis assumed
non-null script->types. However since bug 875276 we don't need this anymore.
Differential Revision: https://phabricator.services.mozilla.com/D13652
--HG--
extra : moz-landing-system : lando
This is just a minor optimization, but it makes the bug fixed by part 2
reproducible when running jit-tests.
Differential Revision: https://phabricator.services.mozilla.com/D13650
--HG--
extra : moz-landing-system : lando
Ensure that "a instanceof b" has Xray semantics, i.e. that when b is a
XrayWrapper, that the wrapped object's getters, `Symbol.hasInstance`
hook and proxy traps are not triggered.
The toolkit/components/mozintl/test/test_mozintlhelper.js test was
updated to explicitly waive Xrays, instead of relying on the previous
behavior where Xrays were automatically waived.
Depends on D11591
Depends on D11591
Differential Revision: https://phabricator.services.mozilla.com/D11592
--HG--
extra : moz-landing-system : lando
There is currently no public API to call the 'instanceof' handler
without triggering proxies. The public method, JS_HasInstance, may
skip the default logic if a class has a non-null JSHasInstanceOp.
(i.e. js/src/proxy/Proxy.cpp and js/src/ctypes/CTypes.cpp ).
To serve the need of the next patch (which needs to trigger the
instanceof logic without triggering the proxy), this patch publishes the
js::InstanceofOperator method.
JS::InstanceOfOperator is the new name, and the new capitalization
matches the name of the abstract operation in the ES6 specification.
Differential Revision: https://phabricator.services.mozilla.com/D11591
--HG--
extra : moz-landing-system : lando
BaseStackFrame is split into two parts:
- BaseStackFrameAllocator is now responsible for dealing with stack
allocation and deallocation in all complex cases (which means
everything except for the simple native masm.Push and masm.Pop
cases).
- What's left of BaseStackFrame is then a simple-to-use API for the
rest of the compiler that maintains and checks invariants and does
various kinds of bookkeeping and hides the remaining differences
between the chunky and non-chunky stacks.
The latter class inherits from the former because this is simplest
(and it's easy to accomplish with 'protected').
There are a couple of minor functional changes here:
- The variable maxFramePushed_ now actually records the maximum value
of masm.framePushed, not the maximum stack height. The new behavior
is correct even with the chunky stack, since this value is used for
stack overflow checking. There should however be no observable
changes because of this. (Trivial reason: only ARM64 is affected
and we have no ARM64 products. Deeper reason: stacks are aligned at
coarser boundaries than our stack chunks, and have lots of headroom.)
- Member variables tracking the stack height are now set up in a new
method, onFixedStackAllocated(), which is called after
beginFunction() has allocated the space for the Header and Local
areas of the frame. The old behavior was correct but very obscure.
The new code is easier to understand.
--HG--
extra : rebase_source : b3a06eb2a845a76c671d3060fa9e77cb0e4e4b69
We rely on TypedObjects for the experimental wasm GC feature, but that
feature is Nightly-only and we should not be touching TypedObjects if
we don't need them. Furthermore we should just fail to compile
outright if wasm GC is enabled but TypedObjects are not.
--HG--
extra : rebase_source : e76a01ea25158aa6d3bd8760339e06be41dbba80
ICEntries and the fallback stub space are now stored in ICScript. The ICScript*
is stored in TypeScript to not increase sizeof(JSScript).
We need this for bug 1499324 but it also lets us greatly simplify the
BaselineDebugModeOSR code as this patch shows.
Note: some ICScript method definitions are still in BaselineJIT.cpp instead of
BaselineIC.cpp to make this patch easier to review. We could move them to
BaselineIC.cpp as a follow-up change.
Differential Revision: https://phabricator.services.mozilla.com/D11746
--HG--
extra : moz-landing-system : lando
This spewer design has two goals:
1. Provide a spew mechanism that has first-class support for slicing and
dicing output. This means that filtering by script and channel should be
the dominant output mechanism.
2. Provide a simple powerful mechanism for getting information out of the
compiler and into tools. I'm inspired by tools like CacheIR analyzer,
IR Hydra, and the upcoming tracelogger integration into perf.html.
Differential Revision: https://phabricator.services.mozilla.com/D11787
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
--HG--
extra : moz-landing-system : lando
These macros tend to be handled quite poorly since the clang-format
tokenizer cannot figure out how to handle them.
Differential Revision: https://phabricator.services.mozilla.com/D13179
--HG--
extra : moz-landing-system : lando
This spewer design has two goals:
1. Provide a spew mechanism that has first-class support for slicing and
dicing output. This means that filtering by script and channel should be
the dominant output mechanism.
2. Provide a simple powerful mechanism for getting information out of the
compiler and into tools. I'm inspired by tools like CacheIR analyzer,
IR Hydra, and the upcoming tracelogger integration into perf.html.
Differential Revision: https://phabricator.services.mozilla.com/D11787
--HG--
extra : moz-landing-system : lando
We have a lot of these arrays and some used clang-format off/on, some are
formatted like a table, etc. We decided it's best to reformat and get rid of
the tabular structure.
Differential Revision: https://phabricator.services.mozilla.com/D13228
--HG--
extra : amend_source : 7b697b5e967c90216c2fcd295a4b7c394ac1a500
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
This is just the first step: the Handler classes are still empty and
BaselineCodeGen contains fields/methods that should eventually move out of
there. That will happen in follow-up patches.
Rooting analysis now reported a hazard in ObjectGroup::getOrFixupCopyOnWriteObject,
this patch has the trivial fix for that too.
Differential Revision: https://phabricator.services.mozilla.com/D12522
--HG--
extra : moz-landing-system : lando
Replace with just unwrapping the key, since there are no users that return anything else for a delegate.
--HG--
extra : rebase_source : e72b825121ca3493364c9347f65e5dddd1ef53e0
It's confusing when looking at Zone.lastSweepGroupIndex() and getting 0 for all the zones being inspected. It made me think it wasn't getting set.
--HG--
extra : rebase_source : abbee63dce2beaf119aa267cb9b00e2448f5e432
This patch removes GCRuntime::temporaryAbortIfWasmGc() and SuppressGC (in
WasmStubs.cpp) and also all the bits of C++ that they guard. It also removes
the seven associated test cases. I verified that each of the seven tests
corresponds to one or more of the removed C++ fragments, so it is safe to
remove them.
--HG--
extra : rebase_source : fe10b50f931a1de20ce306325f25905e9133bc90
This is a first implementation of stack map generation and usage for wasm
baseline. It is intended to be a relatively simple starting point for testing
and refinement. With the patch in place, it is possible to run Wasm test
cases that involve GC objects and garbage collection.
The general way the patch works is:
* During compilation, all state to do with generating stack maps is held in a
new struct, StackMapGenerator. The BaseCompiler updates various fields in
StackMapGenerator as it goes, and can call StackMapGenerator::createStackMap
to create a map.
The StackMapGenerator holds various integer and Maybe-integer fields, but
most importantly it maintains a MachineStackTracker, which is a vector of
booleans which track the pointerness of each word in the current frame
except for pointers corresponding to stack-resident ref-typed entries in the
compiler's evaluation stack.
When we want to create a stack map, BaseCompiler calls one of its four
different ::createStackMap functions. These are simple wrappers which add
various default and other parameters and call onwards to
StackMapGenerator::createStackMap, which does the actual work.
* StackMapGenerator::createStackMap works by augmenting the
MachineStackTracker with pointers that are implied to exist as a result of
stack-resident ref-typed entries in the compiler's evaluation stack
(BaseCompiler::stk_). The resulting entries are then copied off into a bit
vector (a wasm::StackMap) for storage. Extra entries may be added for the
case where a trap exit stub's not-really-a-frame may be pushed over the
current frame. The presence of a ref-typed DebugFrame, if any, in the map,
is also noted.
* All stack maps created also cover those words above the current frame's
return address, that are used to pass parameters in memory to this function.
In other words, the incoming argument area for a function is covered by that
function's stackmap. The alignment padding that may be above that area
*isn't* however included; that belongs (logically) to the caller.
* For places where a function may invoke the wasm trap exit stub (by executing
an illegal instruction), a composite map is created. This contains entries
for the stack entries that would exist in the absence of the stub, but also
contains extra entries for the save area that the stub will push "on top" of
the normal frame. To describe the layout of the save area, a new routine,
wasm::GenerateTrapExitMachineState, generates a description of the area from
which the stackmap component for the save area is computed.
* Completed stackmaps are temporarily stored in BaseCompiler::stackMaps_.
They are further processed in WasmGenerator.cpp:
- ModuleGenerator::linkCompiledCode biases them by the module offset
and moves them to the metadataTier_.
- ModuleGenerator::finishMetadata sorts and sanity checks them
- ModuleGenerator::finish biases them again, so as to give them their
final code addresses, and checks (in debug builds) that they are
associated with plausible instructions.
* When it comes to GC time, TraceJitActivations iterates over activations, and
TraceJitActivation iterates over individual frames. The latter calculates,
in each frame, the address of the next instruction to be executed in that
frame. It hands this, and, effectively, the stack pointer value, to new
function Instance::traceFrame.
* Instance::traceFrame does what you'd expect -- looks up the map, using
Code::lookupStackMap. Then it scans the frame, doing as many sanity checks
as it reasonably can on the way. There are heuristic (but safe) checks to
ensure that the maps sync with the actual stack values, and also that the
map sizes are correct.
* There are 3 new test files:
stackmaps1.js -- tests unwinding w/ maps, for direct/indirect calls only.
stackmaps2.js -- as stackmaps1.js but in the presence of many interrupts
stackmaps3.js -- tries hard to generate many cells which are held live
only from the stack, whilst dealing with interrupts
* New types:
MachineStackTracker -- as described above
StackMapGenerator -- as described above
struct wasm::StackMap -- a single stack map -- basically a bit vector
class wasm::StackMaps -- a mapping from code addr to wasm::StackMap
* The zero value pushed by GenerateTrapExit has been changed to 1337 and had
been given a symbolic name. This isn't entirely frivolous: detecting the
zero in Instance::traceFrame is a useful sanity check, but zeroes occur
relatively frequently in the stack. 1337 is much less likely to randomly
appear. It's not pointer aligned and denotes "page zero" so seems
relatively safe.
Supporting changes:
* JitFrameIter and WasmFrameIter have a new method, returnAddressToFp(), which
produces the address of the next instruction to be executed for both JS and
Wasm frames.
* For all call instructions generated, the relevant MacroAssembler routines
have been modified so as to return a CodeOffset to guarantees to refer to
the first byte of the instruction immediately following the call. This is
so as to ensure that the stack map refers to the correct instruction even in
the case where the MacroAssembler routine adds further instruction after the
actual call instruction.
* Stackmap generation can fail due to lack of memory. So all call chains that
can lead to a call to StackMapGenerator::createStackMap now return a
MOZ_MUST_USE bool and must detect and handle OOMs in the normal way.
* struct BaseCompiler::Stk (evaluation stack elements) has been lifted out to
the top level and placed above struct StackMapGenerator, since
StackMapGenerator needs to be able to inspect stack entries.
--HG--
extra : rebase_source : 726c4cc60644ff86b4a09adb5b21379fa341bebc
We use |2**30 - 2| to ensure the size of a null-terminated char16_t buffer
still fits in int32_t.
The patch adds some tests. I tried to add similar tests for toUpperCase() and
toLocaleUpperCase("lt") (calling into ICU) but it makes the test very slow in debug builds.
Depends on D12878
Differential Revision: https://phabricator.services.mozilla.com/D12879
--HG--
extra : moz-landing-system : lando
To avoid surprises of |cp| copying into a directory vs copying to a new name,
be consistent about using a trailing slash on target directory.
Depends on D11672
Differential Revision: https://phabricator.services.mozilla.com/D11673
--HG--
extra : moz-landing-system : lando
The gyp directory is already copied by the third-party/python line earlier.
Depends on D11671
Differential Revision: https://phabricator.services.mozilla.com/D11672
--HG--
extra : moz-landing-system : lando
