This makes it so we always discard JIT code when the kinds of GC thing we can
allocate in a zone changes. Previously this happened in two separate places for
pretenuring, and didn't happen when we enabled/disabled the nursery.
Differential Revision: https://phabricator.services.mozilla.com/D177272
Benchmark results show that using parallel marking is not always a win for
small heaps, so add a threshold for its use.
This is set to 10MB, which will result in using parallel marking ~70% of the
time.
This parameter is set to zero for jit-tests and shell js tests so we get test
coverage where heap sizes are expected to be small (and maximum performance is
not a goal).
Differential Revision: https://phabricator.services.mozilla.com/D175249
The hazard analysis needs to be able to pass a parameter of type AutoCheckCannotGC&& that can be considered to be "consumed" either explicitly by calling reset() on it, or given over to a calle with std::move().
Differential Revision: https://phabricator.services.mozilla.com/D170142
Wasm{Array,Struct}Objects may be freely nursery-allocated, hence enjoying the
benefits of generational GC. However, those with out-of-line storage in the
C++ heap (called "trailer blocks" in the patch) have those blocks managed by
js_malloc/js_free. This is expensive, and especially for objects which don't
get tenured, undercuts the benefit gained from generational GC.
This patch adds to js::Nursery, two new mechanisms:
* a cache of blocks, js::gc::MallocedBlockCache, which are suitable for use as
trailers. Allocation and freeing of trailers is done mostly from this
cache. A supporting type, js::PointerAndUint7, has also been added, as
extra data (a freelist ID) is needed when returning blocks to the cache.
* a more limited version of the existing Nursery::mallocedBuffers mechanism.
The goal is the same -- to enumerate the subtraction of sets of allocated vs
tenured trailer blocks, at the end of minor GC. The new version differs in
that (1) it tracks PointerAndUint7, not void*s, (2) block resizing is not
supported, and (3) the difference is computed via vector comparison rather
than a hash set, for performance reasons.
An SMDOC explaining the mechanisms in detail has been added to WasmGcObject.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D171551
This also adds a shell option to set the parameter.
Care is taken to avoid using more threads than we start parallel GC tasks for
as otherwise we can deadlock.
Differential Revision: https://phabricator.services.mozilla.com/D167783
Currently we have a GC parameter that allows setting a maximum mark stack
capacity. This is only ever used by test code, not in the browser. This
requires extra unnecessary work in release builds if we move to a different
stack representation as we won't be able to fold the comparison into the
current capacity check as we do now.
The patch makes this feature condtional on JS_GC_ZEAL.
Depends on D160526
Differential Revision: https://phabricator.services.mozilla.com/D160527
Currently we have a GC parameter that allows setting a maximum mark stack
capacity. This is only ever used by test code, not in the browser. This
requires extra unnecessary work in release builds if we move to a different
stack representation as we won't be able to fold the comparison into the
current capacity check as we do now.
The patch makes this feature condtional on JS_GC_ZEAL.
Depends on D160526
Differential Revision: https://phabricator.services.mozilla.com/D160527
Currently we have a GC parameter that allows setting a maximum mark stack
capacity. This is only ever used by test code, not in the browser. This
requires extra unnecessary work in release builds if we move to a different
stack representation as we won't be able to fold the comparison into the
current capacity check as we do now.
The patch makes this feature condtional on JS_GC_ZEAL.
Depends on D160526
Differential Revision: https://phabricator.services.mozilla.com/D160527
This adds a 4GB max limit for GC parameters related to heap size and fixes the
test that set this to an over-large value.
Differential Revision: https://phabricator.services.mozilla.com/D130749
This requires passing the JSTracer through to these APIs. They also get a
boolean return value that simplifies their use a little.
Differential Revision: https://phabricator.services.mozilla.com/D129243
There's a pretty serious bug in bug 1730140 which is that the check for whether
to trace a zone's gray roots only checks whether it is being marked gray, but
we also need to mark these roots when compacting. This only affects GCs when
we're not collecting the atoms zone though because we mark everything in that
case.
So this is a plausible culprit for the crashes here, which would have been
hidden by bug 1728273 since that made all compacting GCs full GCs.
Differential Revision: https://phabricator.services.mozilla.com/D126509