WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
128039
Improve convergence on Octane2/gbemu
https://bugs.webkit.org/show_bug.cgi?id=128039
Summary
Improve convergence on Octane2/gbemu
Filip Pizlo
Reported
2014-01-31 22:22:35 PST
...
Attachments
Add attachment
proposed patch, testcase, etc.
Filip Pizlo
Comment 1
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.
Filip Pizlo
Comment 2
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.
Filip Pizlo
Comment 3
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.
Filip Pizlo
Comment 4
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.
Filip Pizlo
Comment 5
2014-04-29 14:42:44 PDT
Our convergence is pretty good now.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug