Add support for column numbers when profiling JS stack frames and functions. This will help debug minified scripts when inspecting performance profiles. The column information will be emitted as a new column property that is part of the frameTable in the profile output, and will also be appended in the descriptive profiler string.
Differential Revision: https://phabricator.services.mozilla.com/D3059
--HG--
extra : moz-landing-system : lando
These tests loop over every Unicode code point:
for (let codePoint = 0; codePoint < 0x10FFFF; codePoint++) {
// split strings to avoid a super long one;
chunks[codePoint % totalChunks] += String.fromCodePoint(codePoint);
}
With compacting zeal enabled, this is too slow; we disable such tests.
--HG--
extra : amend_source : 2511cf172c7c871d6b97a7fc9abb8dd8562796ea
NOTE: This has a slight effect on TI of certain compare operations. A
previous patch to make SimpleArithOperand more conservative had only
been applied to one copy and then rectifies that.
MozReview-Commit-ID: Fj8d7mWufYC
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
* Introduce a setZone method that changes the zone and the freelist.
* leaveAtomsZone() private
--HG--
extra : rebase_source : 7bb624c9091aaa585211577c486288a548926a71
extra : source : 96e57dd562b890bac534d88ff265653d5a00f61c
JS::ubi::Concrete<T> inherits from JS::ubi::Base but not JS::ubi::Node, so the bare 'Size' in the class declaration refers to Base::Size, not Node::Size. (Note that they're the same underlying type.)
--HG--
extra : topic : gcstats.thresh
extra : rebase_source : 2dd9ccca9e458e4f10bdbb8aff58f08732e712c7
This patch series replaces message manager globals with ordinary JS objects
which live in the shared JSM global. Once that happens,
ExecuteInGlobalAndReturnScope will no longer have useful behavior for them,
since the base global has none of the methods that they rely on, and it
provides no way to insert another plain object into the scope chain.
This patch changes the scope chain for frame scripts to instead look like:
-+- Shared JSM global
|
+- LexicalEnvironment[this=global]
|
+- NonSyntacticVariablesObject
|
+- WithEnvironmentObject[target=messageManager]
|
+- LexicalEnvironment[this=messageManager]
Where lexical assignments end up on the lexical scope, and both qualified and
unqualified assignments wind up on the NSVO.
This has some slight behavioral differences from the previous model, in that
properties defined on the message manager can mask properties on the NSVO. But
those differences are minor, and probably not worth worrying about, since
frame scripts are being deprecated as part of the Fission project.
MozReview-Commit-ID: ACEOY2hExco
--HG--
extra : rebase_source : 384ccd422b4167e9a4fc550dd691fcc027553544
The DOM elements within the UA Widget Shadow DOM should have its reflectors in
the UA Widget Scope. This is done by calling nsINode::IsInUAWidget() which
would check its containing shadow and its UA Widget bit.
To prevent JS access of the DOM element before it is in the
UA Widget Shadom DOM tree, various DOM methods are set to inaccessible to
UA Widget script. It would need to use the two special methods in ShadowRoot
instead to insert the DOM directly into the shadow tree.
MozReview-Commit-ID: Jz9iCaVIoij
--HG--
extra : rebase_source : b7b17be68dcde00cfeb207cb39cf16b486f2ab02
This patch creates the basic structure on how the widget scripts can be loaded
and be pointed to the Shadow Root, from the UAWidgetsChild.jsm.
The UAWidgetsClass class asks for a sandbox from Cu.getUAWidgetScope(), which
calls into XPCJSRuntime::GetUAWidgetScope(). It creates and keeps the
sandboxes, in a GCHashMap keyed to the origin, so we could reuse it if needed.
MozReview-Commit-ID: J6W4PDQWMcN
--HG--
extra : rebase_source : a62b0a22195f09cdb508df72c954e20d18c7bf68
As the aarch64 instruction emitters do not return the BufferOffset of
the access instruction, we have to resort to AutoForbidPools to keep
the metadata emitted at the correct address of the access. Manual
inspection of the assembler code and the addressing modes used reveals
that this is viable, if it's done just so.
I've added comments to highlight the fact that it is a little brittle,
and the AutoForbidPools with an instruction window of 1 instruction
will cause failures if assumptions about the machine code should be
violated accidentally in the future.
--HG--
extra : rebase_source : 892744f1b16e970243ca2b2a11fa476b192cf615
extra : amend_source : e7d33696d0f02a48592d8a73f7eaafa32d443656
Entry storage allocation now occurs on the first lookupForAdd()/put()/putNew().
This removes the need for init() and initialized(), and matches how
PLDHashTable/nsTHashtable work. It also removes the need for init() functions
in a lot of types that are built on top of mozilla::Hash{Map,Set}.
Pros:
- No need for init() calls and subsequent checks.
- No memory allocated for empty tables, which are not that uncommon.
Cons:
- An extra branch in lookup() and lookupForAdd(), but not in put()/putNew(),
because the existing checkOverloaded() can handle it.
Specifics:
- Construction now can take a length parameter.
- init() is removed. Explicit length-setting, when necessary, now occurs in the
constructors.
- initialized() is removed.
- capacity() now returns zero when the entry storage is absent.
- lookupForAdd() is no longer `const`, because it can instantiate the storage,
which requires modifications.
- lookupForAdd() can now return an invalid AddPtr in two cases:
- old: hashing failure (due to OOM in the hasher)
- new: OOM while instantiating entry storage
The existing failure handling paths for the old case work for the new case.
- clear(), finish(), and clearAndShrink() are replaced by clear(), compact(),
and reserve(). The old compactIfUnderloaded() is also removed.
- Capacity computation code is now in its own functions, bestCapacity() and
hashShift(). setTableSizeLog2() is removed.
- uint32_t is used throughout for capacities, instead of size_t, for
consistency with other similar values.
- changeTableSize() now takes a capacity instead of a deltaLog2, and it can now
handle !mTable.
Measurements:
- Total source code size is reduced by over 900 lines. Also, lots of existing
lines got shorter (i.e. two checks were reduced to one).
- Executable size barely changed, down by 2 KiB on Linux64. The extra branches
are compensated for by the lack of init() calls.
- Speed changed negligibly. The instruction count for Bench_Cpp_MozHash
increased from 2.84 billion to 2.89 billion but any execution time change was
well below noise.
With asm.js atomics gone and wasm atomics opting in to standard
trap-based OOB handling, we should never fail to find a trap site. So
assert that we always find it, and remove code that is now dead.
--HG--
extra : rebase_source : 5ae030ab9ac92f48d84328c7ed5048ced299eb20
extra : source : 7dc12de9bf40160f8809bbe4fc16f4b54f6e5fa6
extra : histedit_source : 240aef6bd1195f13789d4da8d28a6698bc3dbbff
A large and mostly mechanical change: Prune the non-JS atomic APIs in
MacroAssembler.h and add many wasm-specific APIs instead.
The three non-JS APIs that remain in MacroAssembler.h could also be
removed but are used in multiple places to implement the JS APIs, and
it seemed fine to just leave them in. They are after all generally
useful.
Note, this patch changes MIPS code so that it compiles, but it does
not insert the necessary emitting of metadata, partly because the
mechanics of that for 64-bit ops on 32-bit systems depends on the
implementation of those 64-bit ops, and partly because I am happy to
let the MIPS maintainers do the work and check it. I have left behind
FIXME comments where changes are needed.
The one additional test case in jit-test is a result of closely
reading existing code and finding a bug that should have caused a
failure, but didn't, once the wasm/asm.js fallback for signal handling
was removed.
--HG--
extra : rebase_source : 4958997adb6050222bcde609dca6d00108c0a8f9
extra : histedit_source : b7fbcf868c60d7079d7827d98c7e7aad2d7d1f32
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
Three interlocking changes here:
- when accessing an unaligned word, access bytes in high-to-low order
- emit metadata for the first (highest) byte accessed
- when accessing a multi-word item (i64, f64), access the highest
addressed word first
Most of these changes are straightforward. In a couple of cases I
un-nested tangled control flows by breaking things into cases; this
leads to a little duplicated code but is IMO much easier to follow.
--HG--
extra : rebase_source : cd3b856b60b22c9e153452e984feeadc64103f25
This is also better security-wise: if we're writing the structured clone in some compartment that shouldn't have access to the underlying data of the ImageData, we shouldn't be giving that access here.
This refactors gc::Cell derived types to start with a uintptr_t-sized
field with the low bits reserved for the GC and uses these bits for
relocation mechanism.
- JSString now stores flags in a uintptr_t. On 32-bit platforms, a
second field is used to hold length.
- Redefine JSString flag bit positions to avoid cell reserved bits.
- Forwarded Cells are now indicated by a reserved flag instead of a
magic invalid-pointer-like value.
- gc::RelocationOverlay now extends gc::Cell
- Update js::Symbol, js::Scope and js::BigInt fields to be compatible.
MozReview-Commit-ID: Cs5OavbHmqK
Add accessor methods so that underlying storage strategy can be changed
later. This patch should not change current behaviour.
MozReview-Commit-ID: IRA53TQShe6
This gcc 4.8.5 workaround (from bug 1316850) is no longer needed because Firefox currently requires gcc 6.1 or later (as of bug 1444274).
MozReview-Commit-ID: 4JFmOYoJnMH
--HG--
extra : rebase_source : f348a629f25f6852250306d969262372460a677a
extra : source : cb42b2192694148ffdf97c3a5c2fabb2578a0ec0
Right now, a lot of test code relies on side-effects of SpecialPowers being
loaded into frame script globals. In particular:
- It forces permissive COWs from those scopes, which allows frame scripts to
pass objects from those scopes to unprivileged content that they otherwise
wouldn't.
- It imports a bunch of helper modules and WebIDL globals which would
otherwise not be available.
Fortunately, this seems to only impact test code at this point. But there's a
real down-the-road risk of it impacting shipping code, which ends up working
in automation due to the side-effects of SpecialPowers, but failing in real
world use.
MozReview-Commit-ID: G27eSSOHymX
--HG--
extra : rebase_source : 1702e63fed719fc92def2bdbbb8a7c53572432db
extra : source : 41bedc526dd6ec6b7e8c7be1c832ac60c81d6263
