Recursion limit differs between jit and nonjit

VERIFIED FIXED

Status

()

Core
JavaScript Engine
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: Jesse Ruderman, Assigned: dvander)

Tracking

({testcase})

Trunk
x86
Mac OS X
testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
(function f(i) { print(i); f(i+1); })(1)

With -j: 
  269675
  InternalError: script stack space quota is exhausted

Without -j:
  3000
  InternalError: too much recursion

I don't know if this is actually a problem, but it surprised me.  Will bad things happen if we fall off trace while thousands of stack frames deep?
(Assignee)

Comment 1

8 years ago
Right now recursion in the JIT is only limited by its internal callstack limit (which is 500). It can keep hitting this limit and pushing interp frames until it runs out of stack space.

Brendan: should the JIT be obeying the interpreter recursion limit?
(In reply to comment #1)
> Brendan: should the JIT be obeying the interpreter recursion limit?

Yes -- maybe one of Igor or me should review that code.

/be

Comment 3

8 years ago
note also bug 514139
(Assignee)

Comment 4

8 years ago
Created attachment 405152 [details] [diff] [review]
fix
Assignee: general → dvander
Status: NEW → ASSIGNED
Attachment #405152 - Flags: review?(brendan)
Comment on attachment 405152 [details] [diff] [review]
fix

Fun -- we were just missing the magic value sometimes, and going way beyond it till we hit some other limit, I take it (with a different exception)?

/be
Attachment #405152 - Flags: review?(brendan) → review+
(Assignee)

Comment 6

8 years ago
(In reply to comment #5)

Yes, exactly. The limit still isn't identical (the test in comment #0 is 3010 JIT versus 3000 non-JIT) but it's no longer completely ignored.

http://hg.mozilla.org/tracemonkey/rev/3a72a9e5ccd7
Whiteboard: fixed-in-tracemonkey
(Reporter)

Comment 7

8 years ago
Hrmm.  jsfunfuzz would be happier if the limits were identical.  What causes them to differ by 10?
(Assignee)

Comment 8

8 years ago
The JIT can construct as many frames as it wants and then push them onto the interpreter stack. So for example, the interpreter's inlineCallCount could be (MAX-1), and the JIT could push 500 frames (its internal limit). Next time the interpreter tries to make a call, it'll throw an exception, but there are ~500 frames over the internal limit. So the inaccuracy could be anywhere in that range.

One way to make the limits identical would be to have the limit of the JIT callstack be MIN(JIT_LIMIT, INTERP_LIMIT - inlineCallCount).

Maybe that's good idea - Brendan, any thoughts?
(In reply to comment #8)
> One way to make the limits identical would be to have the limit of the JIT
> callstack be MIN(JIT_LIMIT, INTERP_LIMIT - inlineCallCount).
> 
> Maybe that's good idea - Brendan, any thoughts?

That's smart, it avoids dropping JIT frames when converting to interpreter frames and hitting the exact limit (leaving uncommitted changes unflushed and changing the error model). Try it, if it works I'll review.

/be

Comment 10

8 years ago
js/src/trace-test/tests/basic/bug520498.js
Flags: in-testsuite+

Comment 11

8 years ago
http://hg.mozilla.org/mozilla-central/rev/3a72a9e5ccd7
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Comment 12

8 years ago
See follow-up bug 522136.

Comment 13

8 years ago
v 1.9.3
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.