801105 - IonMonkey: Regressions in Dromaeo DOM-Attr

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Kannan Vijayan [:djvj]]

See: http://dromaeo.com/?id=181221,181222

We have individual regressions occurring in the following tests:

element.property  (5% slowdown.  The property is just "id", and is a PropertyOp getter.  PropertyOp getters should be handled so I'm not sure where the extra slowdown is coming from here)

element.property = value (more than 20% slowdown.  Property is "id", and is a StrictPropertyOp setter.  Handling setters should take care of this, but JM doesn't handle setters, so it's not fully clear where the perf gains happen here.  It may simply be because Ion ICs this and then always takes the fallback path for the IC, which is costlier than just embedding a non-IC call to SetProperty from the start.  The ideal solution for this would be to handle setters, as that would provide perf improvements across the board, and should blow the JM scores away).

element.expando (About 15% slowdown.  This is a GetElem access where the element being accessed is a string that varies on every access.  Haven't profiled, but I figure that this is generating an IC stub, then filling it up, and then taking the fallback path for the IC every time.  JM can invalidate ICs so it recovers from this pathological case, but IM can't since it can't invalidate ICs.)

Comment 1

[Boris Zbarsky [:bzbarsky]]

> It may simply be because Ion ICs this and then always takes the fallback path for the IC

That seems quite likely.

Comment 2

[Kannan Vijayan [:djvj]]

Implemented calling setter StrictPropertyOps and got some good new numbers:

http://dromaeo.com/?id=182534,182535

Highlights: handling setter calls in ICs takes us to being roughly on-par on overall scores with DOM-Attr.  The breakdown is interesting:

On the "element.property = value" subtest in DOM-Attr, we go from being about 25% slower to 15% faster.

The first run's slowdown on "getAttribute" and this run's slowdown on "element.property" seem to be flukes.  I ran it again and the numbers for that test seem to fluctuate greatly, which leads me to believe that there is high per-run variability in those tests.

However, "element.expando" is consistently slower.  Once again, I'm pretty sure this is because Ion can't invalidate ICs - instead it just "fills up" and then keeps hitting the fallback path every time after that.  I think we can handle this by adding a general megamorphic catch-all as the last stub when know what we're about to fill up the maximum number of stubs in a cache.  It's still not ideal because the IC will execute every single guard in all the other stubs before getting to the catch-all stub, but it should be quite a bit better than hitting the fallback/stubgenerator path on top of that every single time.

Comment 3

[Kannan Vijayan [:djvj]]

Closing this.  Focus on bug 807498 (Disabling Ion ICs) to mop up the rest.