> On Nov 22, 2017, at 4:46 AM, Maurizio Cimadamore > <maurizio.cimadam...@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
