626596 - JM: Different enumeration order (interpreter vs JM) after calling a function on a string literal

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

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

try {
    n("".v())
} catch(e) {}
try {
    function l() {}
    function decodeURIComponent() {}
    print(uneval(this))
} catch(e) {}

Tested on TM changeset 4046ef71ddc2

stdout without -m:

({l:function l() {}, decodeURIComponent:function decodeURIComponent() {}})

stdout with -m:

({decodeURIComponent:function decodeURIComponent() {}, l:function l() {}})

===

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   57677:47729824b12c
user:        Brendan Eich
date:        Tue Oct 26 19:12:40 2010 -0700
summary:     Property enumeration order is altered after a method has been read (601399, r=jorendorff).

Comment 1

[David Mandelin [:dmandelin]]

Seems like it could be important for web compat.

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

This observable difference in enumeration order is because normally the string class wouldn't lazily resolve until decodeURIComponent() is resolved. However, a callprop on a string literal will lazily resolve String from inside the method JIT compiler.

Since this only happens when calling methods on string literals, and the only observable effect is enumeration order on the global object, I don't think this should block.

Comment 3

[Jesse Ruderman]

I call toLowerCase/toUpperCase on string literals fairly often. But I usually don't rely on enumeration order :)

Comment 4

[Brendan Eich [:brendan]]

This is so not a blocker.

We should fix standard class init to be eager and super-fast, memcpy plus pointer fixups. I filed a bug on that but can't spot it atm. Can someone cite it?

/be

Comment 5

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

try {
    w("".l)
} catch (e) {}
try {
    function l() {}
    function decodeURIComponent() {}
    for (let y in this) {
        print(y);
    }
} catch (e) {}


A variant testcase causes the following difference in output, in JM with TI:

$ ./js-opt-64-jm-darwin -m -a -n testcase.js
decodeURIComponent
l

$ ./js-opt-64-jm-darwin testcase.js
l
decodeURIComponent

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Current js shell results for comment #0 testcase:
Interp: ({l:function l() {}, decodeURIComponent:function decodeURIComponent() {}})
JM:     ({l:function l() {}, decodeURIComponent:function decodeURIComponent() {}})
JM+TI:  ({l:function l() {}, decodeURIComponent:function decodeURIComponent() {}})

Current js shell results for comment #5 testcase:
Interp:
l
decodeURIComponent
JM:
l
decodeURIComponent
JM+TI:
l
decodeURIComponent