Closed Bug 1869242 Opened 2 years ago Closed 2 years ago

Use unknown allocation site data to decide whether to disable nursery string allocation

Categories

(Core :: JavaScript: GC, task, P3)

task

Tracking

()

RESOLVED FIXED
123 Branch
Tracking Status
firefox123 --- fixed

People

(Reporter: jonco, Assigned: jonco)

References

(Blocks 1 open bug)

Details

Attachments

(6 files)

Currently we make pretenuring decisions for objects per allocation site whereas for strings it is per zone, and the data we use to make these decisions comes from different places. However the data we gather for the the special 'unknown' allocation sites could be used to make the string pretenuring decision instead.

This would simplify things by using a single system for all pretenuring decisions and allow us to remove data collection in a couple of places. It may also allow us to pretenuring strings earlier if necessary as this data is checked every minor GC rather than every major GC.

This refactors the per-site processing code so we don't have to pass so many
mutable references around and moves some methods to the AllocSite where they
make more sense.

The 'unknown' allocation site is used to track nursery allocations when we
don't have a sepcific allocation site. This is per-trace kind and per-zone, and
the data it collects can be used to make the decision on whether to disable
nursery allocation for a trace kind and zone.

This is better than our current system because it's specific to the trace kind,
and it also means we don't also have to collect data for the original scheme.
It also means we can do the same thing for big ints.

Depends on D196272

This removes the previous approach for disabling the pretenuring and resuming
nursery allocation, and removes exiting data collection that is no longer
needed.

Depends on D196273

Following these these changes some parameters are now no longer used.

For example the new appraoch uses the HighNurserySurvivalPromotionThreshold
constant rather than the pretenuring threshold parameter (and it is set to the
previous default value for the parameter).

Depends on D196274

I don't think it makes sense to set a time goal for debug builds as these are
much slower. This will result in us always using a small nursery size in debug
builds and so we will have reduced test coverage of larger nursery sizes.

Depends on D196275

I am in two minds about adding this test as it could be quite fragile. If it
does cause problems we can remove it however.

This could have caught bug 1867193 though.

Depends on D196276

Pushed by jcoppeard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c3810afe4f19 Part 1: Refactor allocation site processing r=sfink https://hg.mozilla.org/integration/autoland/rev/5ec713ef6a20 Part 2: Use unknown allocation site data to turn on per-zone string pretenuring r=sfink https://hg.mozilla.org/integration/autoland/rev/06dff60b4ac1 Part 3: Use allocation site data to disable nursery pretenuring r=sfink https://hg.mozilla.org/integration/autoland/rev/0a0c1cab20b6 Part 4: Remove GC parameters related to pretenuring that are no longer used r=sfink https://hg.mozilla.org/integration/autoland/rev/fbd4cd90deb4 Part 5: Disable minor GC time goal in non-optimized builds r=sfink https://hg.mozilla.org/integration/autoland/rev/e58c9d225507 Part 6: Add test that our pretenuring system always does what we expect for the splay benchmark r=sfink https://hg.mozilla.org/integration/autoland/rev/72c9cd52ea57 apply code formatting via Lando

Also reduced a lot of noise on AWFY-date-format-xparb-SP-* suite

Blocks: 1864862
Regressions: 1963275
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: