Equality for values -- new analysis, same conclusion

Dan Smith daniel.smith at oracle.com
Wed Aug 21 06:00:31 UTC 2019

> On Aug 20, 2019, at 2:09 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> The VM folks understandably want to avoid perturbing ACMP, especially for legacy code.  We have the option to translate Object== differently between (say) —target 14 and —target 15, where we translate to ACMP for pre-valhalla language levels and to something else for post, where ACMP retains the “false if either operand is a value” semantics, and the new target means “SAME==“.  This is a tradeoff between not creating performance potholes for legacy code which does not use values, and creating a discontinuous behavior when migrating old code forward.  It means code compiled for later JVMs will use a more refined implementation of Object==.  If we believe its acceptable to return false always, it should also be acceptable to return false _sometimes_ but return true when the two values are not externally distinguishable.)  
> Cue Dan to say: “OK, do we have benchmarks that differentiate between the “false if value” and “deep == if value” options?  Do we have reason to believe that the former is better enough to risk the discontinuity?  

+1 to strawman Dan.

I'd also add that if the performance is so bad that we feel the need to give users an opt-out, an opt-out that disappears when you recompile your code is pretty unsatisfying.

Suggestion: let's be more precise about what we mean by "legacy code", and what sort of expectations we have. Something like:

- Old bytecode, no inline classes: no performance regression (type profiling ought to solve this?)
- Recompiled source, no inline classes: same
- Old bytecode interacting with inline class instances: minimize behavioral change*, tolerate slowdown compared to equivalent identity classes
- Recompiled source interacting with inline class instances: same

* Note that SAME== and FAST== both risk behavioral change, but the risk for SAME== is far less—it would involve code that assumes instances of a class can be assumed to be unique and unpublished.

More information about the valhalla-spec-observers mailing list