677019 - TI: Different output with/without options "-n -a" and Array.prototype

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The attached testcase produces different output with option combinations "-j -m" vs. "-j -m -n -a", tested on TI revision 3b40e4462464:

$ $JS -j -m main.js 
f29f27a507e2cba5c41e4489d303b78b209dbf74.js
f7b783e07cd0e61b675319866b62c96b521d3c12.js
f7b783e07cd0e61b675319866b62c96b521d3c12.js

$ $JS -j -m -n -a main.js 
f29f27a507e2cba5c41e4489d303b78b209dbf74.js
f7b783e07cd0e61b675319866b62c96b521d3c12.js
1024

Comment 1

[Christian Holler (:decoder)]

Attachment: Test case for shell (see README file inside).

Forgot the testcase -.-

Comment 2

[Christian Holler (:decoder)]

I have a lot more examples with similar behavior, all contain __proto__ or prototype. I assume these are all related and this bug can manifest not only through Array.prototype.

Comment 3

[Brian Hackett [Laid off!]]

Weird/silly PIC bug.  GETPROP and the associated PIC code make a tacit assumption that they are actually at a GETPROP, which I think cannot represent indexed properties.  This allows them to use js_GetProtoIfDenseArray after checking for '.length', as dense arrays only have .length and indexed properties.  The GETELEM polymorphic IC uses the same mechanism, however, and used the PIC code for an access on the "0" property, which ended up skipping to Array.prototype even though the dense array itself had the property.

This bug is also on trunk (manifests only with -n because of different PIC access pattern induced by recompilation).  Should be harmless but could still get fixed there.  It would also be nice to remove js_GetProtoIfDenseArray entirely I think, I doubt it buys anything with TI.

http://hg.mozilla.org/projects/jaegermonkey/rev/0a6ba466113f