Experiment with storing a header before all cells in the nursery
Categories
(Core :: JavaScript: GC, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox78 | --- | fixed |
People
(Reporter: jonco, Assigned: jonco)
References
Details
Attachments
(5 files)
Currently we store a header containing the zone before strings and bigints allocated in the nursery, but not objects. We could store a header for objects too and this would have several advantages:
- we would have a uniform layout and a simple way of getting the zone for a nursery object
- we could store cell kind flags there rather than in the cell flags bits, which we could then use for other purposes
- we could also use it to store allocation site information for making pretenuring decisions
However it would make the nursery a bit less dense and this might have an adverse effect on some benchmarks.
Assignee | ||
Comment 1•5 years ago
|
||
This factors out advancing to the next chunk and writing the nursery canary from the main allocation function and also uses alignas for making sure the canary is aligned.
Assignee | ||
Comment 2•5 years ago
|
||
This adds a struct for the nursery cell header and uses it for string and big int allocation. It's in gc/Heap.h because it will eventually used by Cell.h which doesn't include Nursery.h.
Depends on D73861
Assignee | ||
Comment 3•5 years ago
|
||
This isn't used for anything except GC probes. Replace this with TraceKind which will be used by future patches.
Depends on D73862
Assignee | ||
Comment 4•5 years ago
|
||
Depends on D73863
Assignee | ||
Comment 5•5 years ago
|
||
This also adds nurseryZone() for when the cell is known to be allocated in the nursery.
Depends on D73864
Comment 6•5 years ago
|
||
(In reply to Jon Coppeard (:jonco) from comment #0)
However it would make the nursery a bit less dense and this might have an adverse effect on some benchmarks.
It could also slow down allocation. Given that more objects are allocated than are evicted, this may have a greater affect than any change (positive or negative) to tenuring performance. I think it's still worth trying, but this is just something that's worth measuring if you can.
Comment 8•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/05ec774d38b6
https://hg.mozilla.org/mozilla-central/rev/4b997ecea448
https://hg.mozilla.org/mozilla-central/rev/f0cc1621d2d0
https://hg.mozilla.org/mozilla-central/rev/283c917f74b3
https://hg.mozilla.org/mozilla-central/rev/936936e05775
Comment 9•5 years ago
|
||
== Change summary for alert #25850 (as of Wed, 06 May 2020 17:27:33 GMT) ==
Improvements:
11% perf_reftest_singletons id-getter-2.html windows10-64-shippable opt e10s stylo 769.88 -> 682.66
8% perf_reftest_singletons id-getter-2.html linux64-shippable opt e10s stylo 674.57 -> 621.31
8% perf_reftest_singletons id-getter-2.html macosx1014-64-shippable opt e10s stylo 778.20 -> 719.55
8% perf_reftest_singletons id-getter-2.html linux64-shippable-qr opt e10s stylo 694.56 -> 642.24
For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=25850
Description
•