1349035 - Extremely bad megamorphic IC behavior on Ember

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine: JIT, defect, P3)

Description

[Tom S [:evilpie]]

We "attach" 164886 MegamorphicNativeSlot, and "only" 47419 NativeSlot. Attach is in quotes, because basically we seem to be trying to attach the same stub 77870 times at ember.js:1231 and 77855 times at ember.js:1229, this doesn't actually happen because we won't actually attach stubs that are exactly the same. I think we should add some kind of counter to maybeTransition, where even when we could attach a stub we give up after a while when we hit the fallback triggered by Megamorphic VM calls too often.

Overall megamorphic stubs seem to fail a lot more often than I would expect.

Comment 1

[Jan de Mooij [:jandem]]

Bug 1348905 should probably improve this.

(In reply to Tom Schuster [:evilpie] from comment #0)
> I think we should add some kind of counter to
> maybeTransition, where even when we could attach a stub we give up after a
> while when we hit the fallback triggered by Megamorphic VM calls too often.

We do transition to Generic when we get too many failures or if we keep seeing "duplicates". The only exception is when it's an Ion SetProp that needs a type barrier - then we count a duplicate stub as attached (because it's possible we added new types and the type barrier will succeed next time). It's not ideal but I'm not sure how to improve this other than setting a "bool failedTypeBarrier" somewhere...

Comment 2

[Tom S [:evilpie]]

I can't actually reproduce this anymore right now, maybe bug 1348905 already fixed the very bad case here.

Comment 3

[Hannes Verschore [:h4writer]]

Should we close this, given comment 2?

Comment 4

[Tom S [:evilpie]]

Yes let's close this, we have enough other bugs about optimizing megamorphic ICs.