Skip to content

Comment on Value Classes Still Need Compiler Sympathyparent

Comments

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).

The 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.

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.

Project 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).

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.