Unable to reproduce this issue on Windows-10 using chrome latest canary M57-57.0.2969.3.  By entering the line "(function () { for(var i = 1000000; i--;) { new XMLHttpRequest(); } })();" in dev console it returns undefined. Observed same behavior on firefox as well.

raninkivlev@ Could you please confirm the above steps is the expected behavior of this issue. If yes, could you please upgrade chrome to latest canary #57.0.2969.3 and recheck for this issue.

Thanks!

I executed the following line on DevTools console on Windows 7:
  (function () { for(var i = 100000000; i--;) { new XMLHttpRequest(); } })();

The following version crashed:
- Google Chrome	55.0.2883.87 (Official Build) m (32-bit)
- Crash Server ID: 07227c1080000000
When observing Windows Task Manager, the memory consumption increased up to ~3.5GB, and then Chrome crashed.

The following version did NOT crash:
- Google Chrome	55.0.2883.87 (Official Build) m (64-bit)
- Google Chrome	57.0.2965.0 (Official Build) canary (64-bit)
The memory consumption increased up to ~1.5GB, and then it decreased. GC looked like working correctly.

Maybe a 32-bit-only issue?

On 57.0.2971.0, 64 bit build, Windows 7, memory usage decreases after a few seconds but it's not the same level as before running the code. Clicking the GC button on the Memory pane of DevTools makes the memory usage go back to the same level.

So, at least, it's not leaking.

---

hiroshige@: Thanks for investigation. Yeah, the 32 bit build crashed for OOM.

Memory team, is there anything that prevents XMLHttpRequest (or more generally ActiveScriptWrappables) from garbage collected inside a for-loop?

I upgraded to the latest version 57.0.2971.0 (Official Build) canary (64-bit). (Windows 7)

Running the line:
(function () { for(var i = 10000000; i--;) { new XMLHttpRequest(); } })();

The console return "undefined", after a certain delay, which is the expected behaviour. During that delay one CPU core is running 100%, and memory is growing. On the moment the execution is finished, the console return "undefined", the CPU returns to a low level, but the memory does not.

More findings on the memory: During the execution, the memory rises at a steady pace. This does not mean, however, that memory is always rising: it sometimes takes a small step back before going a bigger step forward. At the end of the execution, the memory used reaches it's maximum, and is somewhere between 1.4 and 1.9 GB (differs per run). Right after the execution is finished, the memory reduces somewhat to a lower level: to anywhere between 0.1 GB and 1.7 GB (differs per run). This behaviour, that an arbitrary amount of memory is reduced, feels random.

I can confirm that manually garbage collecting using the developer tools does remove the excessive memory.

#4: it is dependent on (Blink) GCs being triggered, but if they are, unreachable objects will be collected. How quickly the system (== v8 and Blink GCs) recognizes the ramp-up in allocations made & overall memory pressure, is a recurring topic and something a memory coordinator will help with, for instance.

I don't think there's anything actionable here for this synthetic testcase.

Please let me make the case that for me, this is an important problem. I am developing a user script for myself that relies on thousands of XMLhttpRequests. Now that does not seems a lot compared to the millions of requests needed in the examples above to make it able to see any change in memory, but things start to differ if the XMLhttpRequests are not empty.

Running this piece of code:

for(let i = 0; i < 3000; i++){
    let xmlhttp = new XMLHttpRequest();
    xmlhttp.open("GET", document.URL, true);
    xmlhttp.send();
}

On the New York Times page (https://www.nytimes.com/), increases the memory by an average of 1.17 GB out of four test runs, which is not garbage collected back. That means, for me, this is an issue. And I repeat: Firefox does not have this problem with garbage collection, therefore I'm forced to use an other browser, even though I do not want that.

For that loop, I expect you to be running into throttling issues -- the browser will not allow you to issue 3k network requests in parallel. Consequently, the requests will be delayed _and_ the XHR instances are still considered active & will not to be GCed until they've become unblocked and the request has actually completed.

I understand that the XHR instances are considered active until all requests are completed. (Although I think that is bothersome, why doesn't it look at each request individually?) But then my question is: why doesn't Chrome garbage collect them after all the requests are finished? I can see in the Network panel of the DevTools that it takes approximately 30 seconds before all the data from the 3000 calls is loaded (and memory doesn't increase further). Shouldn't it then be the case that after those 30 seconds, Chrome cleans the unreachable XMLhttpRequests up?