tree d5b26f17d53fb2d50b2be75cd88663492714fd9e
parent e3a870b4125dbcf5f61acfc1463ab6c8baa0e2e7
author jya@apple.com <jya@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc> 1643266743 +0000
committer jya@apple.com <jya@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc> 1643266743 +0000

REGRESSION(r287684) speedtest.net uses many GB of memory
https://bugs.webkit.org/show_bug.cgi?id=235615
rdar://87830583

Reviewed by Youenn Fablet.

The regression was introduced with r286937 and is a good example of
errors introduced when attempting to optimise things too early.
CachedRawResource::updateBuffer does a search in the accumulating
resource's SharedBuffer, search that was taking O(log(n)+1) prior r286937
where n is the number of DataView segments in the SharedBuffer.
This was simplified as a O(1) operation by using the combined contiguous
SharedBuffer instead.
However, that caused every single intermediary accumulated buffers to be
kept referenced by the XMLHttpRequest SharedBufferBuilder leading to
massive memory use.
In other words:
For each update, we did the following steps:
    - Set m_data to a new big continuous chunk of data that stores all
      received data
    - Create a view of the new data as a SharedBuffer. This SharedBuffer
      references the big continuous chunk above
    - XHR stores a ref to the view, hence keep the big chunk alive.
Each XHR chunk, although small in data that can be accessed, is actually keeping in memory all temporary created m_data chunks.
Following this change, XHR will now only keeps a reference to the new DataSegment added since the last run rather than the entire previous content.

Fly-by: add some comments describing the running of the method.

* loader/cache/CachedRawResource.cpp:
(WebCore::CachedRawResource::updateBuffer):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@288667 268f45cc-cd09-0410-ab3c-d52691b4dbfc