> On Aug 20, 2019, at 2:09 PM, Brian Goetz <[email protected]> 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.
