Bug 65437 – JSC GC lays out size classes under wrong assumptions about expected object size.

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Filip Pizlo]

The typical object allocation in the GC heap is either 56 bytes (strings) or 64 bytes (objects) in 64-bit systems.  Few allocations are ever smaller than this, and it's unlikely that an allocation would ever be less than 4 words, since every JSCell has two words (vtable and structure), leaving only two words for whatever payload the object may have.  The current GC strategy lays out size classes starting at 8 bytes (the size of a double), corresponding to an impossible allocation size on 64-bit platforms and a highly unlikely one on 32-bit platforms.  This has a number of undesirable outcomes.  First, there are more mark bits in a typical MarkedBlock than necessary, leading to both wasted space and decreased locality when accessing mark bits.  Second, it means that almost identical allocation sizes (56 bytes and 64 bytes for instance) require the creation of entirely separate MarkedBlocks.  This may decrease internal fragmentation by as little (1/8th to be precise), but it will lead to higher external fragmentation: for example a string allocation will never be able to reuse space left behind by an object allocation, unless the object-sized MarkedBlock becomes entirely free, and we return it to the free block pool.  The JSC GC should probably space out size classes more widely and start with a larger size class that is more representative of the smallest common allocation size.

[Filip Pizlo]

Created attachment 102466 [details]
the patch

[Filip Pizlo]

This is a 1% win on both SunSpider and V8.

[WebKit Review Bot]

Comment on attachment 102466 [details]
the patch

Clearing flags on attachment: 102466

Committed r92092: <http://trac.webkit.org/changeset/92092>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.