2 ms·
Note 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 curre
by tsimionescu 2mo ago
Note 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 2mo 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 2mo 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 2mo 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).