Issue 756368  has been merged into this issue.

 Issue 752172  has been merged into this issue.

 Issue 748279  has been merged into this issue.

 Issue 686148  has been merged into this issue.

Why do you think these are not representative?

If you add JS code of V8 extras this code gets added to the snapshot. Anything in snapshots is a immortal root for V8 which means you are adding memory overhead.

Upon adding code to the snapshot it should be evaluated if it is actually needed as it will be overhead that is not garbage collectable. 

If they were representative I'd expect to see all the benchmarks move the same way at the same time.

In a real browsing session there are far more random variables mutating the heap layout (input events, load ordering, etc.). In that environment a few hundred bytes of additional unexecuted Javascript would be unlikely to make a measurable difference.

The code we've added to the Streams implementation has been either to improve standard compliance or fix security issues.

I expect  issue 759523  will provide a one-time improvement. Beyond that, I'm running low on ideas except for "rewrite in C++". And I don't believe that adding code in C++ is free either. It just doesn't result in regression reports.

> If they were representative I'd expect to see all the benchmarks move the same way at the same time.

That would assume that the heap layout and GC timing is only influenced by the snapshot layout, which is not the case. Chrome is highly non-deterministic. Furthermore, the alerts are not enabled on all platforms and configurations.

> In a real browsing session there are far more random variables mutating the heap layout (input events, load ordering, etc.). In that environment a few hundred bytes of additional unexecuted Javascript would be unlikely to make a measurable difference.

The difference is that anything in the snapshot is an uncollectable root and will increase the fixed size of an Isolate while regular objects can be collected. 

> The code we've added to the Streams implementation has been either to improve standard compliance or fix security issues.
> I expect  issue 759523  will provide a one-time improvement. Beyond that, I'm running low on ideas except for "rewrite in C++". And I don't believe that adding code in C++ is free either. It just doesn't result in regression reports.

I am not arguing against keeping the code :) I am just pointing out that the alerts represent something real here and that memory consumption is (slightly) regressing in certain scenarios.

Since the regression is not changing the world completely it's just a matter of weighing off the trade offs here, getting the relevant people on board, and deciding that it should stick.

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

The long-term plan is to port to C++ after unified GC is ready.

This happened again in issue 899638 (restricted).

This should be fixed by issue 902633 (reimplement in C++).

Issue 911069 has been merged into this issue.