Design notes for next values iteration

[Dan Smith]

> On Nov 22, 2017, at 4:46 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> One thing that struck me as inconsistent is that we are enhancing almost all a- bytecodes to work with value types as well as reference types. But acmp is weird, as it always return false for values. I think I get where that is coming from (e.g. one possible way would be to do a bit-by-bit comparisons of the two values on the stack but, in doing so, we would tell as equal values that come from different classes but happen to have the same layout).
> 
> The thing that concerns me is that this model really really seems to want to tell the classfile users that there's no distinction between R and Q, and your old good L opcodes can be used freely in the new world too. But acmp is a place where the bytecode writer has to stop and think: am I operating on values? If so I need something else. This seems a sticking point in the design IMHO.

I tend to agree.

Bit-by-bit comparison is not quite the right thing for fieldwise equality, because non-flattened fields may have different pointers but be equal values. So it's a little more complex. (FWIW, we did conclude that floating-point values should be tested with bit equality, even though that doesn't match 'dcmp', because the bits are directly observable.)

I think the motivation for avoiding this in 'acmp' is to keep it as fast as possible, even in the value cases. There's a hope that a significant number of use cases, including in legacy code, have the form "x == y || (x != null && x.equals(y))", and in that case, the left test is purely an optimization (assuming a well-behaved 'equals').

One purpose of the prototype is to explore this hypothesis.

Where you need the full field-equality test, 'ucmp' (prototyped as the 'substitutable' method) is the operation you want. That's probably how I'd interpret '==' in Java.

—Dan