[Webkit-unassigned] [Bug 90347] New: Inline property storage should not be wasted when it is exhausted

[bugzilla-daemon at webkit.org]

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

           Summary: Inline property storage should not be wasted when it
                    is exhausted
           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


Currently JSFinalObjects (i.e. vanilla JS objects created via 'new Object', '{}', or constructor calls to user-defined functions) will have inline property storage, enough for at least 4 properties.  This is a great optimization since it means that for most objects we don't need to perform a second allocation to create property storage, and accesses to properties of small objects are fast.

But things go wrong when the inline property storage is exhausted: we allocate out-of-line storage and move all properties that were inline into the out-of-line storage.  This simplifies property accesses, as it implies that it's always safe to say object->propertyStorage[offset], where object->propertyStorage points to either the inline storage or the out-of-line storage depending on the object size.  But this simplicity comes with three costs: first, wasted memory since the inline storage slots are not reclaimed; and second, execution time penalty when the first out-of-line property is stored since all of the inline properties have to be copied to the out-of-line storage; and third, increased execution time cost for accessing the properties that were previously inline.

A better approach would be to continue to use the inline property storage even when it is exhausted: the first N properties will always be inline and the remainder will be out-of-line.  Since our inline property storage size is tuned for common object sizes, this means that the vast majority of properties in the heap will tend to be inline and will be fast to access.  This will be a performance improvement over the current approach, where as soon as any property overflows the inline storage, all properties are evicted and become more expensive to access.

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