Bug 128039 - Improve convergence on Octane2/gbemu
Summary: Improve convergence on Octane2/gbemu
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Filip Pizlo
Depends on: 128047 128057 128158 128162 128229 128234 128291
Blocks: 112840 132357
  Show dependency treegraph
Reported: 2014-01-31 22:22 PST by Filip Pizlo
Modified: 2014-04-29 14:42 PDT (History)
8 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Filip Pizlo 2014-01-31 22:22:35 PST
Comment 1 Filip Pizlo 2014-02-01 11:34:15 PST
Currently it appears that we jettison FTL-compiled code multiple times, for no apparent reason.  That's dumb.  We shouldn't do that.
Comment 2 Filip Pizlo 2014-02-01 20:43:49 PST
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.
Comment 3 Filip Pizlo 2014-02-01 22:01:35 PST
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.
Comment 4 Filip Pizlo 2014-02-09 23:17:23 PST
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.
Comment 5 Filip Pizlo 2014-04-29 14:42:44 PDT
Our convergence is pretty good now.