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
I initially tried to do this for all helper thread tasks but most of them don't
have any associated runtime to send the telemetry to and this resulted in a
much larger set of changes.
What do you think?
Differential Revision: https://phabricator.services.mozilla.com/D171597
Now that bound functions use a `JSClass` that's not `JSFunction`, we need to give
them a `JSProtoKey` to make (xray) wrapper calls work. This fixes a lot of xpcshell
and browser test failures.
The old implementation used `JSProto_Function`. This patch adds `JSProto_BoundFunction`
and (as much as possible) tries to use the same code paths for it.
Differential Revision: https://phabricator.services.mozilla.com/D170568
This adds a stast phase PARALLEL_MARK which is used for total time on both main
and helper threads. Addtionally, helper threads record PARALLEL_MARK_MARK and
PARALLEL_MARK_WAIT.
The patch also adds three telemetry probes related to parallel marking:
- GC_PARALLEL_MARK_SPEEDUP - Ratio of total helper thread time spent marking to main thread time
- GC_PARALLEL_MARK_UTILIZATION - Ratio of helper thread time spent marking to total helper thread time
- GC_PARALLEL_MARK_INTERRUPTIONS - Number of interruptions/donations per slice
Differential Revision: https://phabricator.services.mozilla.com/D170379
Since CompileGlobalScriptToStencil(FrontendContext*...) is a thin wrapper
around CompileGlobalScriptToStencil(JSContext*...), it makes sense for the
names to match.
jsapi-test testCompileNonsyntactic's test name conflicted with
testCompileScript's, so I renamed it to more precisely match what it is
testing.
Differential Revision: https://phabricator.services.mozilla.com/D169134
Need to fill out jsapi-test for more details and use cases.
ParseGlobalScript() has a stackLimit parameter because I don't expect to
know what the limit for the TaskController task is, or even that the function
is being run by TaskController.
Differential Revision: https://phabricator.services.mozilla.com/D167461
The minimal JS-API spec for the GC proposal allows these types to be used on the
JS-Wasm boundary. So far we have not supported this. This commit updates these
methods so that the types work. This commit does not add support to our JIT
fast paths for exit/entry, so any use of these types will be stuck in the
interpreter entry/exit.
Differential Revision: https://phabricator.services.mozilla.com/D170005
As far as I can tell, SpiderMonkey did not have a quick one-line fprintf(stderr) equivalent that would also go to the Windows debug console.
Differential Revision: https://phabricator.services.mozilla.com/D165225
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
This uses a single vector for all export entries and stores the start positions
for indirect and star export entries separately. The export entries are
returned as spans, and other vectors changed to be returned as spans too to
ease the shell integration.
Differential Revision: https://phabricator.services.mozilla.com/D166187
Original patch by mccr8.
At least for the cycle collector, the purpose of calling unmark gray when
accessing a JS field of a C++ object is to avoid creating references from a
black object to a gray object. However, this particular code is writing
undefined, so that should not be a danger.
This particular code is by its nature dealing with GC things that are gray and
may be about to be GCed, so calling unmark grey can waste a tremendous amount
of time. On a profile of collecting a JS-heavy page, I was seeing 20% of the
100ms CC being spent on it.
The patch uses unbarrieredGet in ModuleScript::UnlinkModuleRecord and adds a
new API to clear a module record's private value without checking whether
associated objects are gray.
Differential Revision: https://phabricator.services.mozilla.com/D165202
Not related to the rest of the bug. This is a simplification so that we set the
supported import assertions once rather than querying the host every time they
are needed.
Differential Revision: https://phabricator.services.mozilla.com/D164914
Add separate `Shape` subclasses. `SharedShape` is now only used for native objects.
This will make it possible to store other data in Proxy/WasmGC shapes in the future.
Differential Revision: https://phabricator.services.mozilla.com/D164212
These two are commonly used together in eval and testing functions so add an
overload and simplify the callers. This also allows transfering buffers in more
cases to avoid additional string copies. Currently only support the char16_t
overload, but in future should also support Utf8Unit overloads.
Differential Revision: https://phabricator.services.mozilla.com/D163552
The mark bitmap is represented using relaxed atomics. Currently we update this
using separate load and store operations where possible as this is more
efficient but this is only possible if there are no concurrent writes.
Parallel marking will perform concurrent writes to the marking bitmap so
requires updates to be performed atomically.
The patch adds methods that are correct in the face of multiple writes
(different threads won't stomp over each others' updates) however the
markIfUnmarkedAtomic method can return false positives. It works out faster
overall to allow this and tolerate multiple threads trying to mark the same
thing at the same time occasionally than to have the extra synchronisation
overhead of avoiding it.
Differential Revision: https://phabricator.services.mozilla.com/D163465
This is more complicated because it needed a change to the public API now we're
not longer returning an array object. The new API is less error prone since
it's no longer possible for the caller to mutate the object returned.
Depends on D163948
Differential Revision: https://phabricator.services.mozilla.com/D163949
The mark bitmap is represented using relaxed atomics. Currently we update this
using separate load and store operations where possible as this is more
efficient but this is only possible if there are no concurrent writes.
Parallel marking will perform concurrent writes to the marking bitmap so
requires updates to be performed atomically.
The patch adds methods that are correct in the face of multiple writes
(different threads won't stomp over each others' updates) however the
markIfUnmarkedAtomic method can return false positives. It works out faster
overall to allow this and tolerate multiple threads trying to mark the same
thing at the same time occasionally than to have the extra synchronisation
overhead of avoiding it.
Differential Revision: https://phabricator.services.mozilla.com/D163465
The off-thread-inner-fcn.js test verifies that ParseContext is using
ErrorContext as AllocPolicy. It seems like a fragile test, so perhaps I should
convert it to a jsapi test.
TempAllocPolicy::assertNotJSContextOnHelperThread() needs to be defined in the
.cpp file because the header would have a circular dependency on JSContext.h if
it #included it. We do want to make sure it is inlined, though, to avoid the
extra function calls.
Differential Revision: https://phabricator.services.mozilla.com/D160697
Reduce struct size by using a tagged pointer for the JSContext/ErrorContext
member, since they are mutually exclusive.
According to JS::PropertyKey, it is better to use XOR instead of `& ~JsContextTag`
because small immediates can be encoded more efficiently on some platorms.
Differential Revision: https://phabricator.services.mozilla.com/D160079
