We're soon going to introduce a new way to distinguish between the two
windows ABIs, so we factor out compiler checks that will need to be
adjusted to limit the amount of changes down the line.
Differential Revision: https://phabricator.services.mozilla.com/D170167
The system calls of releasing a chunk of memory can be costly and should be
done outside the arena lock's critical section so that other threads aren't
blocked waiting for the lock.
Differential Revision: https://phabricator.services.mozilla.com/D166775
As expected, the try job flagged a bunch of test failures when flipping the default `delayedApply` pref to `true`. Some of these failures are legitimate issues:
- When creating a new folder in the tree under "Location", renaming the folder doesn't update its name in the Location field.
- When right clicking a bookmark in the sidebar, and creating a new folder, the folder doesn't get placed before the bookmark, i.e. the insertion point is ignored.
And as you pointed out, tags were being wiped out on blur in the Star/Toolbar panels. These issues have been fixed. The rest of the failures have been fixed in one of these ways:
- Update the test to pass regardless of `delayedApply` setting. This was the preferred method.
- Force the test to use instant apply. This was only done for tests that have an existing delayed apply counterpart.
- Force the entire test suite to use instant apply. This was only done for one file, namely `browser_bookmark_popup.js`. I'll file a bug to spin off a delayed apply version of this suite.
try job with `delayedApply` enabled: https://treeherder.mozilla.org/jobs?repo=try&revision=50e9cdb65feaec07c9519e928caf62042c3df9a4
try job with `delayedApply` disabled: https://treeherder.mozilla.org/jobs?repo=try&revision=1102b5076a79bf08a0e4b073fdf369af97a16ef7
Differential Revision: https://phabricator.services.mozilla.com/D168690
We're about to use it a bit more.
Switch to CancelAndForgetObserver, since we will call it in the future from
other places that aren't frame destruction. This doesn't change behavior of the
existing caller because we call mListener->SetFrame(nullptr), which effectively
no-ops the listener
Differential Revision: https://phabricator.services.mozilla.com/D169985
zlib still uses K&R-style function declarations. As of clang 15, these
are warned about by default, as they've been removed in the latest draft
of C2x; this results in thousands(?) of lines of warnings when building
zlib in-tree.
An issue has been filed at https://github.com/madler/zlib/issues/633,
but the author has stated that they are unwilling to change this until
C2x has actually been published.
For now, just silence those warnings when building zlib.
Differential Revision: https://phabricator.services.mozilla.com/D169842
The structNew/arrayNew builtins allocate a struct/array and zero initialize
all fields and elements. This is fine for struct.new_default and array.new_default,
but is wasted work for struct.new and array.new, which will clobber over the
existing fields. This commit adds new builtins which skip zero initialization.
These builtins must be carefully used, as these GC objects are not fully
ready to be observed until they are initialized by the caller JIT code.
Differential Revision: https://phabricator.services.mozilla.com/D169267
Right now for a GC write, we perform a call to the post-write barrier instance
method. The method then filters if it is necessary. This has the downside of
requiring all registers to be spilled, even if the barrier was not necessary.
This commit adds a new MIR node: MWasmPostWriteBarrier, modeled after a JS
version. This node performs the filtering inline and jumps to an OOL code
stub that spills live registers and performs a call to the instance barrier
method if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D169266
This is the same improvement as the previous baseline patch, skip the
pre-write barrier when initializing a struct/array, as all the fields
are null.
There is one additional change here, we start skipping the pre-write
barrier for storing reference results to the stack. The reason for
this is that reference values on the stack are rooted and do not need
a pre-write barrier to mark them during incremental GC. We were
unnecessarily doing that before.
Differential Revision: https://phabricator.services.mozilla.com/D168621
Baseline can fold the offset of inline struct accesses more aggressively
and reduce memory pressure by reusing the object pointer for the
data pointer.
Differential Revision: https://phabricator.services.mozilla.com/D168617
This commit:
1. Extends AllocSite to support 'wasm' sites that don't have scripts but should be tracked
2. Gives every type definition in a module an allocation site that is used when allocating
This was seen to give a meaningful speedup on the dart barista3 benchmark.
Extending AllocSite is the trickiest part, as it is size sensitive and there are no
bits available. This commit chose to encode 'isWasm' by using a special script pointer.
There may be a better way.
This commit uses AllocSite as 1:1 with a type definition for two reasons:
1. There is no easy way to allocate AllocSites for every allocation instruction
with our current compiler infrastructure. I am also concerned that would dramatically
blow-up our runtime size.
2. Current targets of wasm-GC are nominal languages (object oriented too), and it seems
like we could see some similar lifetime behavior for all instances of a class.
However, we definitely should experiment with different usage of AllocSite, types are
just the easiest start and they showed an improvement.
Differential Revision: https://phabricator.services.mozilla.com/D168616
This commit adds a TraceOffsetVector which is used for storing
pre-computed offsets of reference typed values. This minimizes
interpretation required while tracing.
Differential Revision: https://phabricator.services.mozilla.com/D168615
Globals are kept alive for the duration of the program, this is a strong
hint that what is stored in them will be long lived.
Differential Revision: https://phabricator.services.mozilla.com/D168614
ObjectMetadataBuilder is used for tracking allocations with devtools.
This commit removes support for it while we're optimizing for performance,
we will need to add a dynamic fallback for when devtools is tracking
allocations in bug 1814520.
Differential Revision: https://phabricator.services.mozilla.com/D168613
This commit adds a config flag '--wasm-no-experimental' which disables all
experimental features that have a conditional compile flag. This flag has
a higher precedence than the manual enable flags such as '--enable-wasm-gc'.
This commit then also adds a try task to run with this configuration on
linux64debug. It also runs jit-tests to cover all the wasm tests, but the
important thing is testing that the build succeeds.
Differential Revision: https://phabricator.services.mozilla.com/D166375
These are pretty redundant right now, and not even consistent with what we do with other chunked things (such as tests).
Differential Revision: https://phabricator.services.mozilla.com/D170114
Adds the forced-color-adjust property and ForcedColorAdjust keywords.
Updates tweak_when_ignoring_colors to check for `none` value of that property when determining if a color adjustment in needed.
Adds a check for `none` when styling selections to make sure they can be styled in forced color modes.
Differential Revision: https://phabricator.services.mozilla.com/D169000
During shutdown profiling, test suites were reporting window leaks on shutdown.
After investigating, I realized that we are not setting some
JitcodeGlobalEntries as expired. PROFILER_CLEAR_JS_CONTEXT sets these entries
as expired but it wasn't called in this case where we are destructing
nsJSContext.
This PROFILER_CLEAR_JS_CONTEXT macro is called on other places when we are
doing normal profiling, and the JSContext is being cleaned after the window is
destroyed. But with this addition, we are making sure that right after the
window destruction we are cleaning the JSContext, which makes it more
reliable.
Differential Revision: https://phabricator.services.mozilla.com/D169610
This fixes applyConstraints which re-uses the backend with new settings.
Without this patch stopCapture would unset the delegate but startCapture would
*not* set it again.
Differential Revision: https://phabricator.services.mozilla.com/D170100
