207531 2020-02-11 01:05:02 -0800 CachedResource should purge SharedBuffer if it is a particular type 2020-03-05 18:33:11 -0800 1 1 1 Unclassified WebKit Page Loading WebKit Nightly Build Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=208683 P2 Normal --- 1 ysuzuki ysuzuki basuke beidson ggaren simon.fraser oldest_to_newest 1617300 0 ysuzuki 2020-02-11 01:05:02 -0800 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. 1617301 1 ysuzuki 2020-02-11 01:12:54 -0800 I’ll try this tomorrow. Plan is using Variant<SharedBuffer, String, ...> as data 1617309 2 ysuzuki 2020-02-11 01:53:42 -0800 Seems that blink folks are doing this. We should try. https://docs.google.com/document/d/1v0yTAZ6wkqX2U_M6BNIGUJpM1s0TIw1VsqpxoL7aciY/edit#heading=h.hydebxiwp5hv 1617845 3 ysuzuki 2020-02-11 20:11:39 -0800 We have a path using SharedBuffer as a content when it is ASCII. And seems that Membuster is using this path mainly, so maybe, this does not affect on memory usage of Membuster. But for image case, we should do it. And still, we should do it, but I'll check later since this would not affect on Membuster result. 1618415 4 ysuzuki 2020-02-12 23:40:21 -0800 For CachedImage case, // On Mac the NSData inside the SharedBuffer can be secretly appended to without the SharedBuffer's knowledge. // We use SharedBuffer's ability to wrap itself inside CFData to get around this, ensuring that ImageIO is // really looking at the SharedBuffer. We are already doing this, cool. Other possibility is, 1. non-ASCII string source code 2. script source code compression 3. style sheet source code compression 1618417 5 ysuzuki 2020-02-12 23:47:35 -0800 (In reply to Yusuke Suzuki from comment #4) > For CachedImage case, > > // On Mac the NSData inside the SharedBuffer can be secretly appended to > without the SharedBuffer's knowledge. > // We use SharedBuffer's ability to wrap itself inside CFData to get around > this, ensuring that ImageIO is > // really looking at the SharedBuffer. > > We are already doing this, cool. > > Other possibility is, > > 1. non-ASCII string source code > 2. script source code compression > 3. style sheet source code compression Wait, I need to check whether ImageIO is using this buffer directly or doing some fancy buffering internally.