[Webkit-unassigned] [Bug 29909] New: [V8] Chromium's implementation of ScriptString is awful for XHR's responseText

[bugzilla-daemon at webkit.org]

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

           Summary: [V8] Chromium's implementation of ScriptString is
                    awful for XHR's responseText
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jamesr at chromium.org
                CC: mike at belshe.com


ScriptString is implemented in bindings/v8 as a thin wrapper around
WebCore::String.  This means every append operation calls into String::append()
which allocates a new buffer large enough for the entire string and copies the
data in.  For XMLHttpRequest's responseText object, this means every time new
data is received from the network a new WebCore::String is allocated and
populate with the text received thus far.

This results in memcpy()ing the same data around a lot and making a lot of
allocations and deallocations, but it interacts particularly badly with V8 if
the readystatechange to 3 handler happens to grab a reference to the
responseText object because when this happens V8 grabs a reference to the
WebCore::String backing responseText.  Some sites check the responseText.length
parameter on readyState 3 which means they will create a handle from V8 on
every intermediate WebCore string resulting in quadratic memory use (mitigated
by a very small constant factor, but quadratic nonetheless).   For example, if
a 1MB XHR is received in 32 chunks of size 32K there are a sequence of
WebCore::String's created of sizes:

32k
64k
98k
128k
160k
...
992k
1024k

and a readystatechange event fired at each.  If the script grabs a handle at
each readystatechange handler, up to around half a gig could be kept live until
V8 GC's the handles holding the WebCore::String objects alive.  This is
suboptimal, especially as I suspect it is rare that a script would want to look
at the actual contents of responseText before the download completes.

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