The Iterator Helpers proposal defines 6 lazy synchronous iterator methods,
`map`, `filter`, `take`, `drop`, `asIndexedPairs`, and `flatMap`.
All of these methods are to return the newly defined builtin generators,
which we implement as self-hosted generators that are stored in an
internal slot and thus observably distinct from regular generators.
Differential Revision: https://phabricator.services.mozilla.com/D81743
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
Tooru Fujisawa
Adam Vandolder
Narcis Beleuzu
Steve Fink
Jeff Walden
Kannan Vijayan
Ted Campbell
Csoregi Natalia
Razvan Maries
Sylvestre Ledru
Logan Smyth
Paul Adenot
Noemi Erli
Thinker Li
Jon Coppeard
Andrew McCreight
Yoshi Cheng-Hao Huang
André Bargull
Gijs Kruitbosch
Asumu Takikawa
alwu
Philip Chimento