Bug 65437 - JSC GC lays out size classes under wrong assumptions about expected object size.
Summary: JSC GC lays out size classes under wrong assumptions about expected object size.
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
Depends on: 65458
  Show dependency treegraph
Reported: 2011-07-31 15:10 PDT by Filip Pizlo
Modified: 2011-08-01 02:49 PDT (History)
3 users (show)

See Also:

the patch (1.69 KB, patch)
2011-07-31 15:13 PDT, Filip Pizlo
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Filip Pizlo 2011-07-31 15:10:24 PDT
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.
Comment 1 Filip Pizlo 2011-07-31 15:13:51 PDT
Created attachment 102466 [details]
the patch
Comment 2 Filip Pizlo 2011-07-31 15:19:24 PDT
This is a 1% win on both SunSpider and V8.
Comment 3 WebKit Review Bot 2011-07-31 16:48:43 PDT
Comment on attachment 102466 [details]
the patch

Clearing flags on attachment: 102466

Committed r92092: <http://trac.webkit.org/changeset/92092>
Comment 4 WebKit Review Bot 2011-07-31 16:48:47 PDT
All reviewed patches have been landed.  Closing bug.