Closed Bug 717249 Opened 10 years ago Closed 10 years ago
Assertion failure: !uses->next->next && uses->next->popped && script->code[uses->next->offset] == JSOP
_SWAP, at ../jsanalyze .h:1064
The following test asserts on mozilla-central revision 4de07a341aab (options -m -n -a): .__proto__();
If I had to guess, I'm betting this has to do with the JSOP_QNAMEPART fugliness for property accesses for __proto__. h8
This has not been fixed on m-c changeset 7c7d2a8db7ff (which has bug 716713 included) autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 84036:7ab4f1ebc7cc user: Brian Hackett date: Mon Jan 09 06:29:50 2012 -0800 summary: Backout 54cd89b0f1fa (bug 712714 backout). Talos will probably report fake regressions for this patch, do not back out for this reason.
10 years ago
OS: Linux → All
Hardware: x86_64 → All
Yeah, it's the __proto__ special casing. This bug removes that stuff entirely. It seems only necessary so that the interpreter does not have to check for __proto__ when doing GetProtoIfDenseArray. Interpreter optimizations are no longer necessary/justifiable, and while PICs should still be able to do this stuff they can test for __proto__ before generating code.
Assignee: general → bhackett1024
Attachment #587907 - Flags: review?(jwalden+bmo)
(In reply to Brian Hackett (:bhackett) from comment #3) > Interpreter optimizations are no longer necessary/justifiable Overstated this a bit. Having significant complexity to occasionally save a few cycles while interpreting is not good.
Comment on attachment 587907 [details] [diff] [review] rm fugliness Review of attachment 587907 [details] [diff] [review]: ----------------------------------------------------------------- And there was much rejoicing.
Attachment #587907 - Flags: review?(jwalden+bmo) → review+
Backed out for not building on any platforms except the ones I tested on. https://hg.mozilla.org/integration/mozilla-inbound/rev/408ab9247ef1
Unfortunately the QNAMEPART stuff is also necessary for correct behavior of __proto__ on primitives (which should get e.g. Number.prototype instead of Object.prototype) and there doesn't seem to be an easy/efficient way to fix this. So here's a patch which weakens the assert so that the goofy SWAP; SWAP sequence of bytecodes emitted here is passed through.
Attachment #598057 - Flags: review?(jwalden+bmo)
Attachment #598057 - Flags: review?(jwalden+bmo) → review+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
Automatically extracted testcase for this bug was committed: https://hg.mozilla.org/mozilla-central/rev/efaf8960a929
You need to log in before you can comment on or make changes to this bug.