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
This removes gray root buffering from the first marking slice and traces the
gray roots directly in a later slice. This relies on Heap<T> read barriers
being sufficient to ensure correctness.
This is conservative in that it makes no effort to skip tracing roots added
after the start of GC. It also doesn't trace roots removed after the start of
GC, but this is OK because barriers ensure marking of any observed values.
The gray root tracing callback will be called once per sweep group, which means
we will trace all zone holders and xpconnect gray roots for every group rather
than just once. This should not be a problem in practice as we expect the
number of zones and hence zone groups to decrease with fission.
On the plus side we no longer have to do a virtual dispatch per root traced
(for the buffering tracer), allocate memory for the buffer, or trace each root
twice.
Note that this doesn't make the gray root marking itself incremental yet.
Differential Revision: https://phabricator.services.mozilla.com/D125188
This function is only used by the shell, and then only when --avilable-memory
is passed, but it could be used as a source of parameter values for low memory
systems so we should make them resonable at least.
Looking at this the current normal values are out of date with the defaults,
and one parameter is repeated several times. I'm not sure what happened here.
Depends on D122601
Differential Revision: https://phabricator.services.mozilla.com/D122602
The dedicated zone for self-hosting can now be removed entirely. Also remove the
object cloning code that was only used for the old self-hosting mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D120547
The dedicated zone for self-hosting can now be removed entirely. Also remove the
object cloning code that was only used for the old self-hosting mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D120547
This adds an 'urgent' threshold, which is at a configurable point before we
reach the incremental limit. We calculate how close we are to the limit as a
fraction of bytes remaining until we hit it, giving a value in the range 1 to 0
as we apprach it. Then we increase the slice budget in inverse proportion to
this value, and decreases the allocation threshold for the next slice in
proportion to it.
The value for the urgent threshold is chosen as 16MB since the values for the
incremental limit ratio is chosen so that there is always more than 16MB
between the original GC threshold and the incremental limit. This also allows
the effect to vary from subtle to large over several slices, since alloc
triggered slices are initially 1MB apart.
The calculation is chosen to have no effect at the start (at the urgent
threshold itself), rise slowly but becomes asymptotic as we approach the
incremental limit, with the aim of never reaching this limit.
I couldn't think of a better name than 'urgent threshold'. I think it's
reasonable but it's not very descriptive of how it's used. I'd appreciate any
ideas.
Differential Revision: https://phabricator.services.mozilla.com/D120320
Convert all JS_FRIEND_API to JS_PUBLIC_API. At this point, the JS_PUBLIC_API has
no formal curation process and in practice we add a lot of new features to
JS_FRIEND_API without giving much thought to if they should be public. The
result is that all embedders need to use the friend API in some form and the
distinction has lost meaning.
Going forward, we should continue to use the js/public/experimental directory as
a place to expose new APIs, and in general should strive for high quality of the
APIs that are exposed. If a particular API is tricky or discouraged, comments
explaining that will be more helpful that a losely applied FRIEND_API marker.
Differential Revision: https://phabricator.services.mozilla.com/D117607
This doesn't change the state of this feature which currently enabled, but will
allow us to disable it easily if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D117441
This patch does several things:
- make the counter type int64_t like the work budget parameter (the original purpose of this bug)
- simplify implementation by using a Variant to discriminate between different kinds of budget
- remove the global initialization
- remove makeUnlimited() (and replace uses with assignment from SliceBudget::unlimited())
- add convenience methods to get the original budget parameters
- add basic API tests
The use of Variant had the consequence that we now have to pass SliceBudget by reference now to make the linter happy.
Differential Revision: https://phabricator.services.mozilla.com/D103318
This doesn't change the current defaults, only the comments and default values which were wrong/misleading - see the current call to setGCMode() in the GCRuntime constructor.
Differential Revision: https://phabricator.services.mozilla.com/D102717
This rearranges a few things so that we can run a minor GC inside a major GC
slice, so we don't have to be conservative about collecting the nursery at the
start of a slice.
Differential Revision: https://phabricator.services.mozilla.com/D99366
This rearranges a few things so that we can run a minor GC inside a major GC
slice, so we don't have to be conservative about collecting the nursery at the
start of a slice.
Differential Revision: https://phabricator.services.mozilla.com/D99366
This adds assertions that zone pointers passed in refer to zones we know about
and adds and API that's called when zones are destroyed. It also adds some
standard assertions for other related APIs.
Differential Revision: https://phabricator.services.mozilla.com/D99071
Compare the number of finalizations tenured strings with the number of
strings before a major GC. Stop the string pretenuring once the finalization
rate is too high.
Differential Revision: https://phabricator.services.mozilla.com/D94277
Choose the string pretenuring threshold as 0.55, as it's the most common
pretured rate when the number of strings pretenured exceeds 30,000 in JetStream2
benchmark. (about 0.55~0.57 in my tests).
However this threshold shouldn't have any major impact on benchmarks like Octane,
JetStream2 and Kraken, as in these benchmarks when the pretenuring condition is
met, the tenured rate is 99%.
Differential Revision: https://phabricator.services.mozilla.com/D92762
This simplifies the threshold checks and the decision to make a collection
non-incremental ultimately happens in GCRuntime::budgetIncrementalGC anyway. We
still have telemetry for incremental/non-incremental collections and
non-incremental reason.
Differential Revision: https://phabricator.services.mozilla.com/D92592
This adds a thread count for GC parallel tasks calculated from GC parameters
for a helper thread ratio and max helper thread count. It also adds one to
report the number of helper threads used for GC.
This is slightly complicated by the fact that the helper thread system is
per-process and there are potentially many JS runtimes in a process. I
disallowed setting these parameters from workers (i.e. child JS runtimes), but
there may be more than one non-worker JS runtime so this isn't perfect.
I had to swap the mutex order for the GC and helper thread locks. Whatever
reason they were the other way round seems to have gone and this order makes
more sense to me (I see the GC lock as being 'coarser' than the helper thread
lock).
Differential Revision: https://phabricator.services.mozilla.com/D86725
