v8 doesn't invoke Oilpan idle GCs often enough
Reported by
suraj.lo...@gmail.com,
Apr 13 2017
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36 Steps to reproduce the problem: 1. Simply open the attach file(sample.html) in google chrome. 2. Open Chrome task manager and note down the current memory of that tab. 3. Click on start timer button and check the current memory after some time may be 1 hour and see the difference in memory. For more details, I have attached screenshots. What is the expected behavior? It should revert the memory after some time. It Should properly reclaim objects by the garbage collector? What went wrong? It continuously increases the memory after each API call. and at the last, it says "Aw Snap! Google Chrome ran out of memory while trying to display web page" Did this work before? N/A Chrome version: 57.0.2987.133 Channel: stable OS Version: 8 Flash Version: Please first unzip the sample.zip file, you can find in sample.html just open it in the browser.
,
Apr 13 2017
<!DOCTYPE html>
<html>
<body>
<div id="time">
<h1>Time Sample Timer App</h1>
<button type="button" onclick="getTime()">Start Timer</button>
</div>
<script>
function getTime() {
var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
document.getElementById("time").innerHTML =
JSON.parse(this.responseText).time;
setTimeout(getTime, 1000);
}
};
xhttp.open("GET", "http://date.jsontest.com", true);
xhttp.send();
}
</script>
</body>
</html>
,
Apr 14 2017
It still increasing the memory after each API call. I really wanted to know that, Why google chrome not free up the memory?
,
Apr 14 2017
I have faced same issue in my application. My application works fine in the previous version on chrome. Post March 30 release for chrome (Version 57.0.2987.133 (64-bit)) upgrade, my application started crashing. Memory consumption is going above 2Gb, which was not the case earlier.
,
Apr 15 2017
I'm also facing the browser crash issue from last one week, My application works fine in previous version of chrome but after the new release of chrome on 30th March my application keep crashing with the message "AW Snap, Google chrome ran out of memory while trying to display this webpage." I also face the same issue while using the facebook. for facebook tab chrome was consuming 1.5 GB and with my application sometimes memory usage goes up to 2-3 GB. Any help would be highly appreciated.
,
Apr 17 2017
We're seeing this crash in production on several internally-facing websites at Naughty Dog. It seems to be related to continuously increasing memory use. A page loads and takes about 200 MB, and begins issuing AJAX requests to auto-update. At that point memory use (reported by the Chrome task manager) starts to go up, slowly but steadily. After about 15 minutes of this it can reach 1.8 GB of memory use. Eventually, of course, the tab crashes. The three main sites we are seeing this crash on have very little in common other than JavaScript, JQuery, and AJAX. One is a stock Grafana dashboard, and the other two are custom build/status pages with very different implementations. Since it happens on three extremely different pages our assumption is that it's a Chrome bug rather than a page bug. Best guess (based purely on the symptoms) is a memory leak somewhere in the AJAX path.
,
Apr 19 2017
,
Apr 19 2017
Having been running the #c2 testcase in the background for a couple of days, seeing a very slow buildup in memory use. It appears to be due to XHR ActiveScriptWrappables never being visited, and being found out to be no longer having any activities pending & could therefore be GCed. Blink idle GCs do run once in a while. Setting |xhttp| to null when done with it, is one way to plug this buildup.
,
Apr 19 2017
tyoshino@: Would you take a look at this?
,
Apr 19 2017
If we assume that the testcase is realistic & not pathological, then this is more of a (v8) GC coordination issue than XHR specific. XHR instances are examples of heavy host objects that it'd be good to (try to) flush out once in a while, even under low JS allocation rates.
,
Apr 19 2017
Ah, thanks, now I understand. What is heavy with the XHR object? The responseText in the testcase doesn't look big. Or is the problem that we're creating too many XHR objects?
,
Apr 19 2017
In general, a lot of resources/objects can be left reachable from an XHR instance. That the testcase is about to allocate arbitrarily many XHR instances without any being collected or checked for liveness (wrt external wrapper references), seems a bit wrong.
,
Apr 19 2017
We're reporting the heap size of Oilpan (which includes all DOM wrappers) and the size of other big objects with hand-written AdjustAmountOfExternalAllocatedMemory APIs, assuming that V8 will trigger a GC if there's a big increase in the number.
,
Apr 19 2017
,
Apr 19 2017
,
Apr 19 2017
Yes, not being patient enough :) After an hour+, tracing of ActiveScriptWrappables is triggered, which leads to flushing of these short-lived XHR instances.
,
Apr 20 2017
Re #16: This means that theoretically we would resolve the problem but we are not triggering the GC if we are running out of memory as a last measure?
,
Apr 20 2017
I've been unable to reproduce the "Aw snap" aspect of this report (w/ M59), just the long delay before cleanup GCs trigger.
,
Apr 20 2017
Hannes: Would you take a look at this? It seems like we're hitting the external-memory-accounting problem.
,
Apr 21 2017
,
Apr 21 2017
Assigning to hpayer@, per c#19.
,
Apr 27 2017
Right on, will have a look.
,
May 3 2017
Finally, I got around. I am running ToT. V8 heap remains small throughout the execution. Every second 100B get reported over the API to V8 as external memory. However, overall memory is increasing 10K per second. We probably need to report more to V8. What gets allocated on the Blink side that is 10K big? Blink people: Are we not reporting enough?
,
May 3 2017
You're testing with the sample.html in #2, right? I'm guessing that the string allocated by this.responseText (this is actually the contents of http://date.jsontest.com/) would not be reported to V8. However, if we want to report it to V8, we need to report the memory in the string partition to V8, which should be too much... We could add a special logic to report only the memory consumed by XHR's responseText but it should be a hack...
,
May 3 2017
Uh, I used the original one, not the one in #2. Let me re-run it.
,
May 3 2017
I do not see a difference between the one. Every second 100B get reported to V8 while memory increases by ~10K every second. V8 heap remains unchanged.
,
May 3 2017
If the culprit is the string used by responseText, the options are: 1) report XHR's responseText to V8 2) report the entire PartitionAlloc's memory to V8 3) say that this is an artificial test case and it should be handled by Memory Coordinator when the memory pressure becomes high (I think 1) is a bit too hacky since there are a ton of other attributes that cause the same issue.)
,
May 3 2017
Short term, we would probably need to report more to V8 to solve it. Long term, we should come up with a cleaner way to solve that problem.
,
May 3 2017
If you think 2) is okay, it's not that hard.
,
May 3 2017
Is XHR response Text garbage collected on the Blink side?
,
May 3 2017
Hmm, I'm confused. The responseText is using ScriptString, which should be using v8::String... Maybe the responseText is not a culprit here. In any case all the memory used by Oilpan is already reported via AdjustAmountOfMemory. https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/heap/ThreadState.cpp?sq=package:chromium&dr=CSs&l=1171 So I'm suspecting that some objects in PartiitonAlloc that are not yet reported are increasing.
,
May 3 2017
Hmm, must be then.
,
May 3 2017
If you look into memory consumption over time the blink gc heap is growing the fastest, so the objects have to be on the blink heap. However do not report that much over the API. And if we would report more, it would take forever to perform GC because we have a limit of 64M.
,
May 4 2017
Thanks, Hannes. > If you look into memory consumption over time the blink gc heap is growing the fastest, so the objects have to be on the blink heap. However do not report that much over the API. That sounds strange... ReportMemoryToV8() should be called periodically and the entire memory of Oilpan's heap should be reported to V8. keishi@: Would you mind taking a look at this?
,
May 4 2017
Yeah, it actually matches but it grows super slow. It will take a while to grow until 64 :-/
,
May 4 2017
..and until that time, we've got a ton of v8 wrapper objects holding on to XHR and Event (readystatechange) objects on the Oilpan heap. Idle GCs do run.
,
May 4 2017
We need to make sure that we run a V8 idle GC, that would clean up. We are looking into our heuristics right now.
,
May 6 2017
There seem to be a number of complaints online about Chrome 58 causing Aw Snap errors, especially in Gmail. It happens to me now so many times each session, it is almost unusable. I never ever had Aw Snap errors at all in 57 and before. Don't make me go back to Firefox! :)
,
May 8 2017
We are experiencing the same issue on several websites.
,
May 12 2017
We are also experiencing the same issue on Windows machines. Some times, Chrome shows black & blank screen in application tab while other tabs are still ok. The Chrome Task manager does not show entry for this blank tab and no developer option works for this tab.
,
May 12 2017
(Adjusting title to more accurately reflect what this issue covers.)
,
Jul 29 2017
This happened tonight on http://webmail.earthlink.net/ after working a long time on an email. Checked Chrome version and it updated to Version 60.0.3112.78 (Official Build) (64-bit) so I didn't capture what the version had been during the Aw Snap. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by phistuck@chromium.org
, Apr 13 2017Labels: Performance-Memory Stability-Memory