Hopefully, I'll find the right place to zero the stack or do other stuff just like all of the other times.
(In reply to comment #1)
Dude, it's hilarious. We get one of these every few months.
Splay trees imply essentially always inserting at the root and then having the root point at everything else. Broadly speaking any node that was ever a root will continue to indefinitely have a transitive reference to every node that had been part of the tree at that time.
So, if you have a benchmark, like Splay, and at some point some pointer to the tree gets stuck on the stack and then you add and remove a bunch of things to the tree, then you end up doubling your heap size. This is because that one stuck pointer will refer to all of the nodes that were the "old" tree at the time it got stuck, even if all of the nodes in that old tree get removed from the actual current tree.
But wait, there's more. Because of how removal happens, the stuck pointer will be likely to transitively refer to every node that had ever been part of the tree since when the pointer got stuck until the present time. So, in V8v7/splay, after a pointer gets stuck, you cease to be able to collect any garbage.
Interestingly, this almost never happens in-browser and only happens with the way I run splay in my harness. So, it's not all that alarming.
In all cases when this happens, it's because a pointer gets stuck due to a goof in either OSR entry or in the GC's stack scan. I'm guessing that this bug is due to FTL OSR entry.
It looks like it requires that both splay_() and remove() get compiled with the FTL. I can see the regression if just those two get compiled. If I remove either one of them then the regression disappears.
Ha! This is entirely due to some sloppiness with scratch buffers. I think that we claim to be using one at some point, then we dump a bunch of pointers into it, and then we never "free" it - so the GC keeps rescanning it ad infinitum.
Created attachment 222033 [details]
Comment on attachment 222033 [details]
Landed in http://trac.webkit.org/changeset/162666