Large blobs don't trigger GC, and thus can stick around for a while |
|||
Issue descriptionSince we only have a reference, there is no notion of a blob's size for the blink GC. Thus it can not trigger for GCing blob references, and we end up with browser memory being spent for a while. Mitigations in place already: * We do disk paging, and we try to protect the disk from being totally full, so this won't totally fill up the hdd. * .... Not sure if a huge priority - but we can maybe 1. report blobs if they are > a certain size, so then V8 will be a little more eager to GC, or 2. keep track of total blob size for a renderer, and if it goes past a threshold then we look into poking the GC.
,
Apr 19 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 19 2018
Related to this, somewhat odd, XHR-to-blob does report the size of the blob to V8 as external memory. Not sure I understand the rationale behind only reporting those blobs though and not just all blobs...
,
Apr 19 2018
In the blob system we calculate the amount of 'unshared' memory and report that to UMA. I wonder if we could send this back to the renderer so it can report that to v8? |
|||
►
Sign in to add a comment |
|||
Comment 1 by dmu...@chromium.org
, Apr 18 2017