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.
Created attachment 102466 [details] the patch
This is a 1% win on both SunSpider and V8.
Comment on attachment 102466 [details] the patch Clearing flags on attachment: 102466 Committed r92092: <http://trac.webkit.org/changeset/92092>
All reviewed patches have been landed. Closing bug.