[Webkit-unassigned] [Bug 207531] New: CachedResource should purge SharedBuffer if it is a particular type

[bugzilla-daemon at webkit.org]

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

            Bug ID: 207531
           Summary: CachedResource should purge SharedBuffer if it is a
                    particular type
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: ysuzuki at apple.com
                CC: beidson at apple.com

The detailed memgraph data collected from Membuster is saying there are many large Vectors,
and they are a data segment of SharedBuffer of CachedResources, including CachedScript, CachedCSSStyleSheet, CachedImage etc.
But important thing is that they also have decoded data too! This means we have double-sized data basically so long as CachedScript etc. is held by CachedScriptSourceProvider.

For example, we have CachedScript, and it has decoded string.
This means... We have duplicate data for this script, one in SharedBuffer and one in decoded String.
The same thing can be said for CachedCSSStyleSheet, CachedImage etc.

Instead of destroying SharedBuffer, we have a mechanism destroying decoded data (destroyDecodedData).
But this would not be called so long as CachedScriptSourceProvider is holding this CachedScript.
This basically means that we have duplicate data so long as we are in this page.
If we navigate to the other page, we could purge decoded data (and we could purge CachedResource too.)

For some CachedResource types, we should hold decoded data, and should purge SharedBuffer instead.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200211/e2ce29c6/attachment-0001.htm>