Right now any quickstub that doesn't generate a traceable native will always deep_bail on trace. mrbkap might fix that, but in the meantime, we should generate as many traceable natives as we can. Jason, please punt as desired if you think someone else should review this?

Comment on attachment 420807 [details] [diff] [review] Er, and with the right numbers >+#define JS_DEFINE_TRCINFO_1(name, tn0) \ Could you put the \ back in the column where it was? Clearing the r? bit for now, in anticipation of a patch with a little tidying in it (instead of complaining ;).

Comment on attachment 422903 [details] [diff] [review] Updated to comments Right on.

Pushed http://hg.mozilla.org/tracemonkey/rev/bc8bb2def82d

Backed out: http://hg.mozilla.org/tracemonkey/rev/cab0026ad1ad Something's weird here and we start trying to generate a traceable native for a 9-argument function.

That happened because this logic: + mayTrace = ((haveCallee and + len(member.params) <= MAX_TRACEABLE_NATIVE_ARGS - 3) or + len(member.params) <= MAX_TRACEABLE_NATIVE_ARGS - 2) is bogus. In particular, if len(member.params) == MAX_TRACEABLE_NATIVE_ARGS-2 then it sets mayTrace to true no matter what the value of haveCallee. I've rewritten this code as follows: prefixArgCount = 3 if haveCallee else 2 mayTrace = (len(member.params) <= MAX_TRACEABLE_NATIVE_ARGS - prefixArgCount) and pushed http://hg.mozilla.org/tracemonkey/rev/458b9ca9f777

(In reply to comment #7) > > prefixArgCount = 3 if haveCallee else 2 is a syntax error in Python 2.4.3

Yes, it's python 2.5.x syntax. I was under the impression that we required that anyway for our build nowadays. Is that not the case?

We still support python 2.4 for now.

Pushed http://hg.mozilla.org/tracemonkey/rev/b507d2ad1a3e to not use that syntax.