913749 - Differential Testing: Different output message involving .length

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

try {
     y = Float32Array(11);
     x = new Array;
     Object.defineProperty(x, 18, {
         get: (function() {
             y.length;
         }),
     });
     this();
 } catch (e) {}
 try {
     y = undefined;
 } catch (e) {}
 try {
     print(x);
 } catch (e) {}
 try {
     print(x);
 } catch (e) {}

prints nothing on js opt shell on m-c changeset 3697f962bb7b without any CLI arguments but prints:

,,,,,,,,,,,,,,,,,,

with --ion-eager.

My configure flags are:

CC="clang -Qunused-arguments" AR=ar CXX="clang++ -Qunused-arguments" sh /Users/skywalker/Desktop/js-opt-64-dm-darwin-mozilla-central-146034-3697f962bb7b-oqFA2p/compilePath/js/src/configure --target=x86_64-apple-darwin11.4.0 --enable-optimize --disable-debug --enable-profiling --enable-gczeal --enable-debug-symbols --enable-methodjit --enable-type-inference --disable-tests --enable-more-deterministic --with-ccache

Comment 1

[Jan de Mooij [:jandem]]

Attachment: Patch

The problem is that we add MUnbox(MIRType_Object, Fallible) followed by MTypedArrayLength

Then DCE eliminates these two instructions and we no longer bailout and throw an exception when the input is |undefined|.

I think fallible unbox instructions should be marked as Guard. I will check benchmarks before landing this but I doubt it will matter.

Comment 2

[Hannes Verschore [:h4writer]]

Comment on attachment 801520 [details] [diff] [review]
Patch

Review of attachment 801520 [details] [diff] [review]:
-----------------------------------------------------------------

I think this patch is reduced to a one-liner since revision bug 909717 landed.

Comment 3

[Jan de Mooij [:jandem]]

Attachment: Patch

Rebased and it's indeed a one-liner now. Running some benchmarks now.

Comment 4

[Jan de Mooij [:jandem]]

The patch has no effect on SS/Kraken/Octane.

Comment 5

[Hannes Verschore [:h4writer]]

Comment on attachment 802972 [details] [diff] [review]
Patch

Review of attachment 802972 [details] [diff] [review]:
-----------------------------------------------------------------

Seems fine for me, since we don't have a regression.

It might be worthwhile for the future to remove the guard annotation on Unbox[Fallible] if we see that DCE its scope is limited by it. In that case we will need to use TypeBarrier/MGuardObject for these cases. For now it's a bit too tedious to find all cases where we should use Unbox[Fallible] that might get removed and TypeBarrier/MGuardObject that can't get removed.

Comment 6

[Jan de Mooij [:jandem]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2b4aa0f8515e

Comment 7

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/2b4aa0f8515e