3 ms·
Yes, this was the idiom in the 90s, but Escape Analysis has not proven to be powerful enough to optimize away identity. And looking at all the edge-cases and p
by DarkNova6 1mo ago
Yes, this was the idiom in the 90s, but Escape Analysis has not proven to be powerful enough to optimize away identity.
And looking at all the edge-cases and possible data-races via tearing, declaring something as a value must be an explicit design decision that cannot be inferred by a compiler or optimizer alone.
- tsimionescu 1mo agoNote that tearing is NOT a risk for value classes in Java - the JIT compiler is not allowed to optimize the layout of any value class that can tear on the current architecture (so, for any value class larger than 64 bits on x86-64).
- DarkNova6 1mo agoThe tradeoff being that tearing is what enables flattening. So if you truly want the best performance (cache lines etc.) you must enable it. But whether your data’s integrity can be broken by such must be decided by the class author.
- tsimionescu 1mo ago> The tradeoff being that tearing is what enables flattening. Yes, exactly. > So if you truly want the best performance (cache lines etc.) you must enable it. Someone was saying that this is planned as an option in some future version of Java. As it stands, this is just not possible, and to me this suggests that the performance gains from Project Valhalla in this Java will be minimal.
- DarkNova6 1mo agoProject Valhalla is not a JEP, it's a collection of JEPs and this is just the very first one. Flattening has been the goal from the start, but it's simply not something that's delivered in this JEP. But even so, people should not overestimate the effect of values and flattening. The biggest advantage will come from specialized libraries (stuff like OpenCV), and overall library enhancements (Tuples not requiring a dedicated indirection).