Closed Bug 531629 Opened 15 years ago Closed 13 years ago

TM: Continual MISMATCH exits with array creation, prop cache fill

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: duncan.loveday, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression, testcase)

Attachments

(2 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 2.0.50727) Build Identifier: Local m-c build The example below produces continual MISMATCH exits. The statement 'var x="obj=" + {};' seems to be the root cause however the one-deep recursion is also a requirement. $ cat x.js function mismatch(call, firstPass) { print("==== call=" + call + ", firstPass=" + firstPass); var x="obj=" + {}; for (var n=0;n<4;n++) { var values=["ww"]; var v=values[1]; } if (firstPass) mismatch(call, false); return; } // No loop mismatch(1, true); mismatch(2, true); mismatch(3, true); mismatch(4, true); mismatch(5, true); $ Reproducible: Always $ export TMFLAGS=tracer $ ./js -j x.js | grep -e exitType -e ==== ==== call=1, firstPass=true leaving trace at x.js:6@72, op=lt, lr=00D262E0, exitType=LOOP, sp=2, calldepth=0, cycles=0 ==== call=1, firstPass=false leaving trace at x.js:6@72, op=lt, lr=00D262E0, exitType=LOOP, sp=2, calldepth=0, cycles=0 ==== call=2, firstPass=true leaving trace at x.js:6@72, op=lt, lr=00D262E0, exitType=LOOP, sp=2, calldepth=0, cycles=0 ==== call=2, firstPass=false leaving trace at x.js:9@58, op=getelem, lr=00D26640, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 ==== call=3, firstPass=true leaving trace at x.js:9@58, op=getelem, lr=00D26640, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 ==== call=3, firstPass=false leaving trace at x.js:9@58, op=getelem, lr=00D26640, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 ==== call=4, firstPass=true leaving trace at x.js:9@58, op=getelem, lr=00D26640, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 ==== call=4, firstPass=false leaving trace at x.js:9@58, op=getelem, lr=00D26640, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 ==== call=5, firstPass=true leaving trace at x.js:9@58, op=getelem, lr=00D26640, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 ==== call=5, firstPass=false leaving trace at x.js:9@58, op=getelem, lr=00D26640, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 leaving trace at x.js:9@58, op=getelem, lr=00D26190, exitType=MISMATCH, sp=2, calldepth=0, cycles=0 $
Blocks: 530956
Keywords: testcase
Keywords: regression
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
Just to show the effect on performance, using 100K loop iterations Without MISMATCH exits $ ./js -j x.js Time=1781 recorder: started(4), aborted(1), completed(3), different header(0), trees trashed(3), slot promoted(0), unstable loop variable(2), breaks(0), returns(1), merged loop exits(0), unstableInnerCalls(0), blacklisted(0) monitor: exits(10), BRANCH(0), CASE(0), DEFAULT(0), LOOP(10), NESTED(0), MISMATCH(0), OOM(0), OVERFLOW(0), UNSTABLE_LOOP(0), TIMEOUT(0), DEEP_BAIL(0), STATUS(0), RECURSIVE_UNLINKED(0), RECURSIVE_LOOP(0), RECURSIVE_MISMATCH(0), RECURSIVE_EMPTY_RP(0), RECURSIVE_SLURP_FAIL(0), RECURSIVE_SLURP_MISMATCH(0), timeouts(0), type mismatch(0), triggered(10), global mismatch(0), flushed(1) $ With MISMATCH exits $ ./js -j x.js Time=23639 recorder: started(4), aborted(2), completed(2), different header(0), trees trashed(2), slot promoted(0), unstable loop variable(1), breaks(0), returns(1), merged loop exits(0), unstableInnerCalls(0), blacklisted(0) monitor: exits(700003), BRANCH(0), CASE(0), DEFAULT(0), LOOP(3), NESTED(0), MISMATCH(700000), OOM(0), OVERFLOW(0), UNSTABLE_LOOP(0), TIMEOUT(0), DEEP_BAIL(0), STATUS(0), RECURSIVE_UNLINKED(0), RECURSIVE_LOOP(0), RECURSIVE_MISMATCH(0), RECURSIVE_EMPTY_RP(0), RECURSIVE_SLURP_FAIL(0), RECURSIVE_SLURP_MISMATCH(0), timeouts(0), type mismatch(0), triggered(700003), global mismatch(0), flushed(1) $ No JIT $ ./js x.js Time=3328 $
This isn't really related to recursion, it's just bad general behavior in the tracer. The code after the inner loop (CALLPROP) causes a property cache fill and a shape change on |Array.prototype|. The outer loop never gets a clean compile and the inner loop always exits.
No longer blocks: tracerecursion
Attached file test case w/out recursion (deleted) —
recorder: started(5), aborted(3), completed(2), different header(0), trees trashed(2), slot promoted(0), unstable loop variable(1), breaks(0), returns(0), merged loop exits(0), unstableInnerCalls(0), blacklisted(1) monitor: exits(9982), timeouts(0), type mismatch(0), triggered(9982), global mismatch(0), flushed(0) keima:src dvander$ TMFLAGS=tracer ./Debug/js -j c.js | grep exitType | grep MISMATCH | wc -l 9980
Is the 'var x="obj=" + {};' essential ? I started with a function that produced high MISMATCH exits but didn't have that statement (was recursive). Whilst reducing the test case I added the latter statement in error and that immediately produced lots of exits. I was rather pleased with myself until I realised my original didn't have it and the reduced test case doesn't produce exits without it - so might not be the same issue I started with at all.
No I don't think it's necessary, but I didn't try yet so I can't say for sure. Certainly it is _a_ problem, so it's a good find either way.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: TM: Continual MISMATCH exits in a recursive function → TM: Continual MISMATCH exits with array creation, prop cache fill
Attached file Slightly reduced testcase (deleted) —
This is a further reduced case, however something silly, of the form 'var x="" + {}' seems essential. I suppose that makes this an edge case really.
Attachment #415236 - Attachment is patch: false
Attachment #415236 - Attachment mime type: text/plain → application/x-javascript
Current JS shell perf numbers for the original testcase (modified to loop 100000 times): Interp: 580 JM: 281 JM+TI: 89 d8: 117 Current JS shell perf numbers for the reduced testcase (modified to loop 100000 times): Interp: 515 JM: 306 JM+TI: 133 d8: 112 Interesting that JM+TI and v8 switch spots in the two testcases. Also, I'll note that the JM+TI numbers tended to bounce around a lot more than the v8 numbers. The testcase in comment #0 gives the same output in Interp, JM, JM+TI, and d8.
Blocks: 467263
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: