In the JIT frame sampler, we apply the appropriate category in addition to
the "implementation" field. For JS frames (IS_JS_FRAME), we identify as
either BaselineInterpreter or Interpreter. Note that JS_Other still applies
to various places we enter SpiderMonkey outside of RunScript.
Differential Revision: https://phabricator.services.mozilla.com/D79524
Replace the duplicate lists in mozglue/baseprofiler/public and js/public with
a shared list. Add this list to both moz.build files so it is published twice
which simplifies supporting different standalone configurations.
Differential Revision: https://phabricator.services.mozilla.com/D79520
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One effect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One affect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
This patch bases on the work of krystalyang2 with minor bug fixes.
The patch includes several major parts,
1. mark nursery strings pointed by tenured strings as
non-deduplicatable,
2. deduplicate strings when they are moved to tenured from nursery, and
3. adjust dependent strings to correct their pointers to the base
string and external buffer after tenuring.
4. reorder store buffer processing to trace the string whole cell buffer
first, since strings traced through the whole cell buffer need to be marked
non-deduplicatable.
(Part 4 was originally phabricator D77715 but is now merged in here.)
Differential Revision: https://phabricator.services.mozilla.com/D74366
Previously there was a quirk of nursery size rounding where requesting a nursery size of just less than a chunk resulted in a smaller size than a chunk being used even if one chunk was the nearest valid size.
This was to avoid having a sub-chunk size greater than the amount of usable space in a chunk, but that is not possible anyway as long as the sub-chunk step is greater than the chunk trailer size.
The patch simplifies the rounding code and updates the test code to add a size that will give different results depending on chunk size. I had to add a gcparam to get the chunk size to make this work.
Differential Revision: https://phabricator.services.mozilla.com/D79148
Introduce an IS_BLINTERP_FRAME flag to ProfilingStackFrame to distinguish C++
and Baseline interpreter frames. In the profile data this sets the
"implementation" to "blinterp".
Differential Revision: https://phabricator.services.mozilla.com/D78725
Round the number of reserved flag bits up to 16. This leaves 16-bits for the
category (so 64k subcategories). Also make the baseprofiler consistent.
Differential Revision: https://phabricator.services.mozilla.com/D78724
Also add `JS::WasmModule::createObjectForAsmJS` which is similar to
`createObject` but does not set the WasmModule prototype. Also mark these
methods as const so they work with the `SharedModule` definition.
Differential Revision: https://phabricator.services.mozilla.com/D78088
Implement Iterator.from static method from the Iterator Helpers proposal.
Involves adding a WrapForValidIterator object and prototype that is used
to wrap iterators returned by `Iterator.from`.
Differential Revision: https://phabricator.services.mozilla.com/D77178
This adds an extra pref for whether the cleanupSome method is exposed and renames the existing pref. We can turn on the pref to expose cleanupSome to get test262 coverage in the browser.
Differential Revision: https://phabricator.services.mozilla.com/D77267
The main problem here is that we sweep weak caches off-thread, and when we finish sweeping a hash table the Enum class' destructor can rehash or resize the table, causing store buffer entries to be added or removed (since the table may now contain nursery pointers).
To address this the patch adds a store buffer lock and establishes that all off-thread store buffer access from inside the GC must take place with this lock held. The changes to GCHashSet/Map are a little gross; perhaps it would be better to add an explicit API to hash tables to allow us to postpone the rehash/resize operations but I haven't done that here.
Other complications are:
The TypeSetRef generic buffer entries can contain pointers into TI data that is moved during sweeping. We therefore do need to collect the nursery if there are any of those present. This was relatively rare in testing.
Finally, swapping objects can result in pointers into dying objects being put in the whole cell store buffer (because we do tricks with skipping barriers when we remap wrappers to not keep otherwise dead wrappers alive). We need to collect the nursery if these are present to prevent them being accessed after the dying objects are finalized.
Differential Revision: https://phabricator.services.mozilla.com/D77831
Some platforms have variable polarity for the IEEE-754 NaN signalling bit.
This patch allows those platforms to compute the appropriate value at
startup. The NaN must still meet the requirements of ValueIsDouble.
Differential Revision: https://phabricator.services.mozilla.com/D76573
This patch removes the compile-time and run-time flags that disable BigInt/I64 so that the feature can be shipped. It also adjusts/removes tests as appropriate to account for the removed code paths.
Differential Revision: https://phabricator.services.mozilla.com/D74142
This patch will do :
- create a sub-category `Cubeb`
- add `Cubeb` profiling labels in related codes
The advantage of doing so :
- allow us to know the percentage of time respectively we spend on cubeb and non-cubeb codes
More details :
The profiling code would include `<atomic>` which is C++ only, so I can't use the label in `cubeb.c` directly. Instead, I add labels on the `AudioStream` and `AudioCallbackDriver` where we would call cubeb related methods.
Differential Revision: https://phabricator.services.mozilla.com/D74172
This patch will do :
- create a profiling category `Media`
- add `Media` profiling labels in related codes
The advantage of doing so :
- allow us to easily see what operations are related to media playback from the profiled report
More details :
According to the description in the `ProfilingCategory.h`, `topmost profiler label frame in the label stack determines the category pair of that stack`. Therefore, most labels I added are the first task would run on the thread, in order to ensure all its following tasks can be marked as the media playback label as well.
Differential Revision: https://phabricator.services.mozilla.com/D74171
From the existing usage of the function, it seems like it should either
take a JSErrorReport with no toStringResult, or a JS::ErrorReportBuilder
where it can get both the JSErrorReport and the toStringResult.
Differential Revision: https://phabricator.services.mozilla.com/D73523
From the existing usage of the function, it seems like it should either
take a JSErrorReport with no toStringResult, or a JS::ErrorReportBuilder
where it can get both the JSErrorReport and the toStringResult.
Differential Revision: https://phabricator.services.mozilla.com/D73523
Implements the spec changes from: https://github.com/tc39/proposal-weakrefs/pull/187
The spec change removes the `FinalizationRegistryCleanupIterator` in favour of
calling the clean-up callback for each finalised value. It also allows to call
`cleanupSome()` within the callback function.
`FinalizationRegistryObject::cleanupQueuedRecords()` has been changed to iterate
from back to front, because this allows us to call `GCVector::popCopy()`, which
makes it more efficient to remove entries from the `records` vector.
Differential Revision: https://phabricator.services.mozilla.com/D70821
To make sure that `<input>` elements with `pattern` attributes update their validation state (`:invalid`) properly, nsContentUtils::IsPatternMatching needs to be able to distinguish between parsing errors caused by an invalid pattern, vs parsing errors caused by OOM/overrecursion.
This patch also fixes up the places inside the new regexp engine where we can throw over-recursed to make sure that we set the right flag on the context, then fixes regexp/huge-01.js (and the binast variants) to accept a different error message.
Differential Revision: https://phabricator.services.mozilla.com/D74499
Implements the spec changes from: https://github.com/tc39/proposal-weakrefs/pull/187
The spec change removes the `FinalizationRegistryCleanupIterator` in favour of
calling the clean-up callback for each finalised value. It also allows to call
`cleanupSome()` within the callback function.
`FinalizationRegistryObject::cleanupQueuedRecords()` has been changed to iterate
from back to front, because this allows us to call `GCVector::popCopy()`, which
makes it more efficient to remove entries from the `records` vector.
Differential Revision: https://phabricator.services.mozilla.com/D70821
We can reduce the size of the SSO by removing the element slot entirely, and instead retrieve the element through a callback function. The callback will take in the value in the private slot of the SSO, which is either a LoadedScript* (from the browser) or a JSObject* (from the shell). In addition, this removes the requirement of having a script dom element ready when parsing a JS script which can open up new opportunities for performance.
Differential Revision: https://phabricator.services.mozilla.com/D70417
To make sure that `<input>` elements with `pattern` attributes update their validation state (`:invalid`) properly, nsContentUtils::IsPatternMatching needs to be able to distinguish between parsing errors caused by an invalid pattern, vs parsing errors caused by OOM/overrecursion.
This patch also fixes up the places inside the new regexp engine where we can throw over-recursed to make sure that we set the right flag on the context, then fixes regexp/huge-01.js (and the binast variants) to accept a different error message.
Differential Revision: https://phabricator.services.mozilla.com/D74499
Introduce JS::IsBaseTraceType to check if a type is the canonical type
associated with a TraceKind. Use this with SFINAE to make footguns turn into
compile errors.
Differential Revision: https://phabricator.services.mozilla.com/D74869
To make sure that `<input>` elements with `pattern` attributes update their validation state (`:invalid`) properly, nsContentUtils::IsPatternMatching needs to be able to distinguish between parsing errors caused by an invalid pattern, vs parsing errors caused by OOM/overrecursion.
This patch also fixes up the places inside the new regexp engine where we can throw over-recursed to make sure that we set the right flag on the context, then fixes regexp/huge-01.js (and the binast variants) to accept a different error message.
Differential Revision: https://phabricator.services.mozilla.com/D74499
These pragmas can be used to influence stack trace filenames, and to affect
how and where files show up in developer tools. In some circumstances, it can
be nice to disable allof that functionality in order to ensure that you get
the stack trace and debug information as SpiderMonkey sees it.
Differential Revision: https://phabricator.services.mozilla.com/D72103
Remove (unused) ability to clone TransitiveCompileOptions& since we now
expect these options to no long vary within a compilation. The only cloning
of CompileOptions should be of the complete ReadOnlyCompileOptions set in
order to make adjustments before the compile starts.
Depends on D73694
Differential Revision: https://phabricator.services.mozilla.com/D73695
The nonSyntacticScope and skipFilenameValidation options do not vary
throughout compilation so they should be TransitiveCompileOptions.
Differential Revision: https://phabricator.services.mozilla.com/D73694
We add a configuration option for SIMD and apply ENABLE_WASM_SIMD
throughout the engine as appropriate, mostly to insert #error or
MOZ_CRASH where things need to be done in later patches or for
architectures that we won't currently consider.
We add a command line switch for the shell and an option for
about:config and plumb the value of this through the engine.
Differential Revision: https://phabricator.services.mozilla.com/D57940
Previously this stored a function pointer to do the tracing along with the rooted thing. The patch changes this to use a virtual method for the tracing. Calling the method on the base class means we don't need to do address arithmetic to find wher the trace function is stored and we don't need the alignment restrictions, because the virtual trace method knows the layout of its class.
I had to add a traits class, mainly to get the address of the rooted thing inside the wrapper since we need to be able to get the address of the wrapper itself now for tracing.
The wrapper class is renamed from DispatchWrapper to RootedTraceable.
Differential Revision: https://phabricator.services.mozilla.com/D73421
Since the parsers have a virtual trace method already we can handle these by making them CustomAutoRooters and get rid of the special kinds.
Differential Revision: https://phabricator.services.mozilla.com/D73297
This also allows us to remove JSID_FROM_BITS and gives us stronger assertions everywhere for the whack integer-string case.
Differential Revision: https://phabricator.services.mozilla.com/D72564
I am honstely still not convinced that this function should actually exists.
It seems like a convulted way of saying AtomToId, while also asserting that the atom is pinned.
Differential Revision: https://phabricator.services.mozilla.com/D72563
We can reduce the size of the SSO by removing the element slot entirely, and instead retrieve the element through a callback function. The callback will take in the value in the private slot of the SSO, which is either a LoadedScript* (from the browser) or a JSObject* (from the shell). In addition, this removes the requirement of having a script dom element ready when parsing a JS script which can open up new opportunities for performance.
Differential Revision: https://phabricator.services.mozilla.com/D70417
This requires adding a new JSOptions field (for internal use within the shell),
as well as a new browser pref (to support possible Cranelift benchmarking on
aarch64).
Differential Revision: https://phabricator.services.mozilla.com/D72907
This adds a splits the non-incremental threshold parameter into one for small heaps and one for large. What counts as large and small are controlled by the existing parameters that were previously used for dynamic heap growth. I also renamed the parameter from "non-incremental threshold" to "incremental limit".
The small heap parameter is increased to 1.4. This avoids non-incremental GC on facebook and reddit as reported in the dependent bugs and allows us to remove the splay latency hack that was previously necessary.
Differential Revision: https://phabricator.services.mozilla.com/D72903
The `mozilla::IsPod<HashMapEntry` specialisation was only needed for the static
assertions in "js/src/frontend/NameCollections.h". Part 3 removed those, so we
can now also remove `mozilla::IsPod<HashMapEntry`.
Drive-by change:
- Remove no longer needed "mozilla/PodOperations.h" include in mfbt/HashTable.h.
- And then fix up previously transitively included files for RootingAPI.h,
jsfriendapi.h, and Bench.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D69201
The idea here is to set a flag whenever GC yeilds to the mutator while waiting for a background task (either sweeping or decommiting). Then when the task completes we check the flag and request a GC slice if it's set.
Differential Revision: https://phabricator.services.mozilla.com/D71770
This adds WrappedPtrOperations and MutableWrappedPtrOperations specialisations for Maybe<T> to all basic Maybe operations to used on Rooted<Maybe<T>>, Handle<Maybe<T>>, etc. I didn't add all of them; in particular I found ptr() would conflict with the Rooted::ptr data member.
This also adds JS::NothingHandleValue for passing Nothing to a Handle<Maybe<Value>>.
Differential Revision: https://phabricator.services.mozilla.com/D71555
The natural way to represent v8::Object is as a thin wrapper around a JS::Value. However, Value is MOZ_NON_PARAM and alignas(8), and irregexp uses objects as parameters. There are two plausible solutions: stop marking Value as MOZ_NON_PARAM, or stop storing a Value inside Object. I wrote a set of patches to do the former, but nbp pointed out in the bug I created that "the intent of alignas(8) was to ensure that 'doubles' are well aligned when loaded/stored as floating points values."
If we want to keep the annotations on Value, then we have to change Object instead. I tried rewriting it to store raw bits, and the patches seem alright, so I'm going with that unless somebody has a good reason not to.
Differential Revision: https://phabricator.services.mozilla.com/D71361
A while back we added a heuristic to delay a GC if it would cause a reset (bug 1367455), but it was turned off after it caused a performance regression and hasn't been reenabled since.
Telemetry shows that that only 0.2% of GCs get reset anyway so we should probably just remove this.
Depends on D71328
Differential Revision: https://phabricator.services.mozilla.com/D71329
This is checkd in the allocator on every allocation, but we also check this when we allocate a new arena in maybeAllocTriggerZoneGC. It's possible that this one will hit first if background sweeping reduces the heap threshold after the last arena was allocated, but this doesn't really make any difference.
Differential Revision: https://phabricator.services.mozilla.com/D71328
This tracks the total memory used by the nursery's malloced buffers set and trigers a minor GC if it passes some limit. The limit is somewhat arbirarily defined as eight times the nursery capactity - this only fires rarely in normal use but is enough to prevent runaway memory growth in this case.
Depends on D71041
Differential Revision: https://phabricator.services.mozilla.com/D71042
--HG--
extra : moz-landing-system : lando
Now that we have some per-zone vectors we can skip tracing those for zones that are not being collected.
Differential Revision: https://phabricator.services.mozilla.com/D68523
--HG--
extra : moz-landing-system : lando
This defines a constant for the number of reserved bits in a public header and does some tidying up.
Differential Revision: https://phabricator.services.mozilla.com/D68335
--HG--
extra : moz-landing-system : lando
This patch adds the boilerplate necessary to support a new regexp flag. Externally visible changes (parsing the flag, the dotAll property on the prototype) are guarded behind ENABLE_NEW_REGEXP. Note: RegExpFlagsGetter turns out to be externally visible because it can be called on a non-regexp object with the dotAll property defined.
The actual implementation of dotAll comes for free with the fresh import of irregexp (bug 1367105).
There are two tests (tests/non262/RegExp/prototype.js and tests/non262/RegExp/flags.js) that need to be updated when this is turned on to add s/dotAll to the list of expected properties on the RegExp prototype. I will attach those changes to my patch that flips ENABLE_NEW_REGEXP to be on by default.
Differential Revision: https://phabricator.services.mozilla.com/D66844
--HG--
extra : moz-landing-system : lando
Also reenable the `static_assert` which was disabled for some reason in
bug 1308236. (Bug 1308236 doesn't contain any information why this assertion
had to be disabled.)
Differential Revision: https://phabricator.services.mozilla.com/D67662
--HG--
extra : moz-landing-system : lando