Idea Capture: Size Class Feedback via AllocSites
Categories
(Core :: JavaScript: GC, enhancement, P3)
Tracking
()
People
(Reporter: mgaudet, Unassigned)
References
(Blocks 1 open bug)
Details
I just want to capture an idea that came up today in our discussion:
Sometimes we are allocating objects, too small. We don't know that we are doing this, but then we need to make them bigger, or we need to use the more expensive dynamic slot lookup code.
It would be nice if when we allocate objects, we could actually choose the correct size.
One way that we could do this is for nursery allocated objects when we generate dynamic slot look ups inside of baseline ICs we could provide feedback to the associated allocation site, which is accessible from the word before the header pointer on what the dynamic slot size is.
By collecting this information in the allocation site, we could decide what size class to use for the object dynamically in much the same way that we currently do when choosing to allocate tenured or nursery.
|
||
Comment 1•3 months ago
|
||
A good first step would be an experiment to see how often Baseline ICs / transpiled Ion code generate accesses to dynamic slots with indices <16, indicating that we could have allocated the property in a fixed slot if we'd made it bigger to start with. That would give us an indication of how often this occurs in practice.
In bug 1823811, we got a 3% improvement on matrix-react by improving size estimates for constructors, so there's some reason to believe that allocating properties into fixed slots is valuable.
Note that changing AllocKind (eg AllocKind::Object4 to AllocKind::Object12) dynamically is harder than changing which heap we allocate an object in, because a different AllocKind implies a different shape.
Description
•