[Webkit-unassigned] [Bug 65437] New: JSC GC lays out size classes under wrong assumptions about expected object size.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Jul 31 15:10:24 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=65437

           Summary: JSC GC lays out size classes under wrong assumptions
                    about expected object size.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: fpizlo at apple.com


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 wi
 ll 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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list