...
Currently it appears that we jettison FTL-compiled code multiple times, for no apparent reason. That's dumb. We shouldn't do that.
It looks like two things are going wrong here: 1) The GC is collecting the main structure associated with GBEmu's state. 2) ToThis never realizes that it should stop speculating badly if the GC resets its structure. (2) is a progression for the FTL because it fixes the rage-recompilations, but it's a regression for the DFG because we lose out on GetById/PutById optimizations. The overspeculation on ToThis is the only thing that's giving us information about structures! It's pretty funny.
There appear to be at least two reasons why the GC is collecting the main structure: 1) On the first run of GBEmu, it adds a property called "secondaryBuffer", but doesn't add it in subsequent iterations. Interestingly, if we hadn't collected the structure, then everything would more-or-less work: we'd have a set of polymorphic GetByIds and PutByIds - but we know how to handle those. 2) Even if you hack the benchmark to always add "secondaryBuffer", the structure is still being collected. It's not clear exactly why, but there is clearly a second reason. The nightmare of all of this is making me have second thoughts about our handling of weak structures. It's true that the GC often saves us by telling us that a particular structure will never be used again. That's pretty cool. But it then also sometimes has us think that a heap access is entirely unoptimizable even though it became fine after a one-off clearing by GC. I still need to think more about this.
As of http://trac.webkit.org/changeset/163765, the FTL is a speed-up on gbemu even without any warm-up. That's pretty good. I'll keep this bug open because I think we can do even better.
Our convergence is pretty good now.