651509 - Bound methods extracted from boxable primitive values do not have reliable identity

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Virgil Palanciuc]

Try this code:
==================================
var n = NaN;
trace(n.toString== NaN.toString);
trace(n.AS3::toString == NaN.AS3::toString);
==================================

On my machine, it prints "true false"; shouldn't it print "true true"?

Comment 1

[Lars T Hansen]

You're comparing function pointers, is that the intent?

If so: I'm not 100% sure that we specify what happens with extracted ("bound") methods, such as AS3::toString.  In the implementation they get cached with the class, but they're weakly held, so a well-timed GC could make a comparison fail.  Also, for "primitive" values such as Number I'm not sure that bound methods necessarily behave the same way.

If it were me (and I guess it will be me, at some point :-) I would spec it so that bound methods do not have object identity, ie, "true true" and "true false" would both be legal results.

Comment 2

[Dan Smith]

> If it were me (and I guess it will be me, at some point :-) I would spec it
> so that bound methods do not have object identity, ie, "true true" and "true
> false" would both be legal results.

Should we then consider this bug as RESOLVED/INVALID?  Any reason to keep this open?

Comment 3

[Lars T Hansen]

(In reply to Dan Smith from comment #2)
> > If it were me (and I guess it will be me, at some point :-) I would spec it
> > so that bound methods do not have object identity, ie, "true true" and "true
> > false" would both be legal results.
> 
> Should we then consider this bug as RESOLVED/INVALID?  Any reason to keep
> this open?

Let me run it by the spec team and see what they say first; at a minimum we'd like to capture the oddity in the spec prose, and this is not a bad time to do it.

Comment 4

[Lars T Hansen]

I wrote:

> In the implementation they get
> cached with the class, but they're weakly held, so a well-timed GC could
> make a comparison fail.

That's a bogus argument, as the GC would not reap the object if we're holding onto it for the purpose of a future comparison.

But the point about primitives still stands.

Comment 5

[Lars T Hansen]

Turns out that bound functions are not dynamic, yow.  This means that identity for them has much less utility.

Comment 6

[Jeff Dyer]

I think we may be over generalizing by saying this bug affects all primitives. I think it is specific to NaN values.

Observe the following:

- - - - 
function f() {
   var n = NaN;
   print(n==NaN, n.AS3::toString === NaN.AS3::toString);  // false false
}

function g() {
   var n = 10;
   print(n==10, n.AS3::toString == 10..AS3::toString); // true true
}

function h() {
   var n = NaN;
   var m = n;
   print(n==m, n.AS3::toString === m.AS3::toString);   // false true
}


f(); g(); h()

- - - - 

It appears that the VM is handling references to NaN and inline NaN differently when it comes to comparing methods bound over them.

Comment 7

[Lars T Hansen]

It is not specific to NaN.  Consider this variant:

var y = 10;
var x = y*2/3*3;

function gg() {
   var n = x;
   print("G");
   print(n==10, n.AS3::toString == 10..AS3::toString); // true false
}

The problem is that MethodClosureClass::create() keys on object identity.  There can be several objects that have the value 10, and in the example above I construct a unique one by performing some arithmetic.  You got tricked in your original example because the "10" values are both small integers and small integers do not suffer from that problem.

Comment 8

[Lars T Hansen]

Scratch that, the example is obviously corrupted...

Comment 9

[Lars T Hansen]

One more time:

var y = 10.5;
var x = y*2/2;
print(x);

function gg() {
   var n = x;
   print("GG");
   print(n==10.5, n.AS3::toString == (10.5).AS3::toString); // true false
}

This prints true false because object identity of the number is used and one 10.5 is not the same object as the other 10.5.

Comment 10

[Lars T Hansen]

Incidentally this means that optimization may change the meaning of the program, consider the case where ASC had optimized the computation of x above, in that case there would have been only one object holding 10.5 in the program.

Comment 11

[Lars T Hansen]

So why do we see a difference between f() and h()?  Initially I thought this could be because the global NaN value is a getter, but it isn't, it's a constant binding with initializer 0/0 and type Number.  The reason is that in f(), the JIT loads the untagged value from the global NaN twice and tags it twice, creating two distinct boxes, while in h() the value is only tagged once and stored in the temp, whose value is then used.  If the JIT had more aggressive optimization we'd not see the problem in h(), but we could still construct a program a la gg() that would exhibit it also for NaN.

Comment 12

[Lars T Hansen]

Also a problem for strings - this prints "false":

  function f() {
    return ("a" + "b").AS3::toString === "ab".AS3::toString;
  }
  print(f());

Maybe also a problem for namespaces, not sure what the intended semantics of namespaces are, whether they have object identity or not.

Comment 13

[Lars T Hansen]

QRB: requesting that this be targeted to "Future" and unassigned.

Comment 14

[Lars T Hansen]

QRB request timed out.

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Tamarin is a dead project now. Mass WONTFIX.

Comment 16

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.