765980 - IonMonkey: Fix earley-boyer performance

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[David Anderson [:dvander] - inactive, e-mail if emergency]

We're spending a huge amount of time in the interpreter on this benchmark, and it appears the same is true in JM+TI as well. In JM+TI we recompile 112 times. In IM (--no-jm) we have 80 invalidations that are unique for an invalidation session. In most cases it looks like we land in the interpreter because of a failing type barrier and in at least one instance, we invalidate 80 copies of a function on the stack.

Fixing this will most likely make JM+TI much faster too, but I'm not 100% sure on that.

Comment 1

[Nicolas B. Pierron [:nbp]]

(In reply to David Anderson [:dvander] from comment #0)
> In IM (--no-jm) we have 80 invalidations that are unique for an
> invalidation session.

Last time I had to check for that I clean-up the invalidation messages but I don't recall seeing any list of 80 invalidations, maybe a stack with 80 Ion frames/activations in which lots of frame had been invalidated but not 80 invalidations. It would be interesting to check if this is always the same property which is causing these invalidation.

One other issue is that Earley boyer is changing constantly between Ion monkey frames and something else.  If this something else is the interpreter we may expect a lot of performance issue from this point. Calling js_DumpBacktrace from the ThunkToInterpreter should help at detecting what is between Ion activations.

Comment 2

[Brian Hackett [Laid off!]]

Do you know how much time is spent in the interp?  112 recompilations is a lot but since the test runs for a full second the interp time shouldn't be a huge % of execution time if we're able to compile everything.  How many of the recompilations are due to GCs throwing code away?  Also, what does behavior / performance look like when the test runs for longer?

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

Okay, I got a better performance view of this now. We definitely have a large number of recompilations but indeed that doesn't seem to be a big factor. I also don't see any evidence of interpreter/JIT transitions.

With bug 766428, --no-jm gets 8% faster than with JM+Ion, so some tuning is needed. bug 766218 and bug 766468 should help considerably too. After that, we need inlining of functions which use |arguments|. Beyond that, it looks like we spend a lot of time in GC finalization so maybe we need generational GC there.

I'll profile again once some of this stuff has landed.

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

This still needs investigation. IonMonkey's score is about 15,600 to Crankshaft's 32,000. Increasing our score by 105% would raise our V8 score by about 9%.

Comment 5

[Hannes Verschore [:h4writer]]

Attachment: Top lirs where we spend our time in the internals

Comment 6

[Hannes Verschore [:h4writer]]

For now removing myself as assignee. The performance is mostly blocked on GGC. After GGC lands I'll probably look again into these issues.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 12 votes.
:sdetar, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.