578727 - JM: Integrate Method JIT and Trace JIT

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

Continuing work from bug 549522. I'm going to tackle raw integration in this bug, then file a follow-up for tuning the heuristics intelligently.

Comment 2

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

So far, the overhead of adding an empty stub call to the edge of every loop in SunSpider looks to be about 3% (~20ms) on my machine.

Comment 3

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

Just to clarify: this is not the overhead we'll have. The tracer invocation is going to be a MIC, and blacklisting (for whatever those heuristics end up being) will reroute the backedge jump, reducing the cost to 0.

comment #2 was establish an upper bound.

Comment 4

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

Attachment: WIP v1

I've hit a not-too-serious snag. The tracer can bail out at opcodes that aren't "safe points" (i.e. no resumable point in the method JIT). That's fine, there's a function PartialInterpret() that'll try to reach a safe point with the interpreter.

The problem is that the PartialInterpret() can hit a JSOP_RETURN,STOP,RETRVAL etc and leave, and those aren't safe points. So, like the imacro-removal loop, we'll need another loop to unwind frames as long as the current frame is about to return.

So far this patch can handle simple loops and some function calls.

function () {
  var i = 100000000;
  while (true) {
    if (i-- == 0)
      break;
  }
}

dvander@dvander:~/mozilla/moo/js/src$ ./Opt32/js -m r.js 
198
dvander@dvander:~/mozilla/moo/js/src$ ./Opt32/js -m -j r.js 
221
dvander@dvander:~/mozilla/moo/js/src$ ./Opt32/js -j r.js 
221

Hrm... heuristics for things like this will be fun. (FWIW, tracing does better when that loop is in global scope).

Comment 5

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

Whelp, idea in comment #4 doesn't always work. Calls aren't safe points, so we can't return beyond the entry frame of the trace. The stacks are basically corrupt (by design), so PartialInterpret() dies. We also can't resume at the RETURN, since it's not a safe point either.

(Note: This is situation is quite common - we trace out of loop edges and hit the end of the function.)

The JIT's calling convention is that the rval must be in ECX:EDX, and the next return address in EAX. As long as we can fake this state, it's safe to pop the entry frame and return to the caller. Wedging a trampoline in should do the trick.

New patch tomorrow.

Comment 6

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

Attachment: WIP v2

New strategy for returns. Now working through the test failures.

Comment 7

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

Attachment: WIP v3

Down to failing ~16 tests.

Comment 8

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

Attachment: WIP v4

Turns out most of the JM1 logic for getting back into mjit code from the tracer does not apply. So it's now all torn out. We can't get back to the mjit with anything other than original frame we started tracing from. However, we can still be smart and try to re-enter JaegerShot at every opportunity.

Down to 6 failures, 5 of which are trace stat differences, and 1 which appears to be a correctness bug in 3d-raytrace.

Comment 9

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

Narrowed down two of the tests to a bug where I had copied LAMBDA from the interpreter incorrectly, and INITMETHOD optimizations to avoid cloning weren't happening.

http://hg.mozilla.org/users/danderson_mozilla.com/moo/rev/b3da5ad59382

Comment 10

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

Attachment: WIP v5

Down to three trace-test failures:
    basic/testComparisons.js
    sunspider/check-3d-raytrace.js
    sunspider/check-date-format-tofte.js

Comment 11

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

Passing tests, pushed: http://hg.mozilla.org/users/danderson_mozilla.com/moo/rev/c25ead2d20d3

No integration.
ss, -m versus -j: http://pastebin.mozilla.org/751079
v8, -m versus -j: http://pastebin.mozilla.org/751080

Integration, basic blacklisting:
ss, -m versus -m -j: http://pastebin.mozilla.org/751086
v8, -m versus -m -j: http://pastebin.mozilla.org/751087 

Notes on the strategy:
 * Recursion is now disabled.
 * We have to interpret (and if possible, mjit) our way back from any
   frames the tracer left, to the original frame. This might end up
   factoring into our heuristics.
 * To preserve as much compatibility as possible, this patch lets us
   keep tracing if ICs are disabled, if the method JIT is disabled, or
   if a method does not JM compile.

We get around an 8.5% SS win with this "dumb" integration. v8 needs work - 8% slower, most of this in crypto and earley-boyer. These should be priorities for tuning heuristics.

Nonetheless, these results are promising. It's pretty clear we'll get *some* win. Filing a follow-up bug.