With the patch for bug 886911, we have 44 minor GCs on Sunspider date-format-xparb. We create many Date objects and writing doubles to their slots seems to fill up the store buffer. If I add "if (v.isObject())" checks to the callers of HeapSlot::post in Barrier-inl.h, there are no minor GCs while the benchmark is running and time is about as fast as non-ggc builds (17 ms -> 11 ms).

This bug + the generic buffer overflowing seems to be causing the Octane-pdf.js slowdown as well. With the patch in bug 888313 + this patch I get numbers that are very close to non-ggc builds. These patches also seem to win 15-20% on Kraken crypto-aes, crypto-pbkdf2 and crypto-sha256-iterative. Pretty cool, I've looked at these tests before and always hoped/assumed GGC would help us a bit, good to know that a lot of the difference there is indeed GC related.

This is actually not a terrible hack, but something that came from some misunderstanding. Apparently we used to think that just putting everything into the store buffer is a good idea, and that we should only check for objects once we iterate over it. I believe this was also fueled by how v8 checks this. They scatter the |IsObject| check all over the codebase, for no important reason. I think I actually wanted to file a bug that we should do something like this as an optimization. How much does this patch win without the is-in-nursery check?

It looks like bug 889682 should have fixed this too.