654705 - TI+JM: v8-richards performance regression

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jan de Mooij [:jandem]]

Score with -n -m went from 5400 to 4200 points. This is a regression from http://hg.mozilla.org/projects/jaegermonkey/rev/f1f907de8765, bug 649376.

Comment 1

[Brian Hackett [Laid off!]]

A couple performance fixes for richards.

Allow generation of native and full call stubs at ICs within inlined frames.  We didn't do this before because of some extra complexity it brings to inline frame expansion (also, before the interpoline this wasn't really possible for native stubs).  Without this, we were taking a slow call at the 'this.task.run' in 'TaskControlBlock.prototype.run,' which really killed perf.  Fixing this brings JM+TI about even with JM+TM.

http://hg.mozilla.org/projects/jaegermonkey/rev/f8159830d8b7

Constant fold 'x != null' type comparisons where the 'x' cannot be null or undefined.  Previously we stubbed these.  There are a few pretty hot cases of this, in Scheduler.prototype.{queue,release}.

http://hg.mozilla.org/projects/jaegermonkey/rev/12b2b8e6d6d0

This leaves scores for me at:

d8: 12031
js -m -n: 7375
js -m -j -p: 6460

Will file a separate bug for tracking richards perf improvements, there's still a lot left to do here.  Richards does very little allocation, the gap between engines is due to compiler optimizations and codegen.