The initial flattening in Project Valhalla relied on four property value types had at the time: lack of identity, immutability, null-freeness, and non-atomicity. As our understanding of value types improved, we realized that null-freeness was not a property inherently part of value types, and that non-atomicity was too challenging to include in the Java language for a first release. So, JEP 401 defines value class instances as identity-less and (mostly) immutable. The value class model has also been relaxed, allowing field inheritance through abstract value classes. All these modifications, combined with the constraints of the Java Memory Model and the limitations of current hardware, created new challenges for the JVM to be able to flatten values. New flattening schemes had to be developed and are presented in the talk.

As the Valhalla team explored new flattening solutions, it became obvious that flattening is a multi-faceted problem. Flattening is beneficial to memory density: by removing object headers and the indirection pointer, Java heap space is used more efficiently. The spatial locality of the value and its container can lead to better cache efficiency, but a flat value can also have a higher access cost than a non-flat value, especially if properties such as nullability and atomicity must be guaranteed. Memory density can also be improved by using clever encodings to make the most of every bit of the flat representation. However, complex encodings usually have a higher access cost and have a significant impact on the code complexity in the JVM. The talk will explain the different trade-offs JVM engineers had to make when implementing the flattening policies.

With an improved prototype, benchmarks helped us understand the kinds of improvements flattening can provide, and which scenarios can be negatively impacted. Flat arrays accessed by C2 compiled code were, and remain, the ideal scenario for achieving a significant boost in application raw performance. Field flattening initially performed poorly in comparison until its impact on GC workload was measured. Finally, if C2 is able to exploit flat values to their maximum, other VM components like the interpreter, the runtime, or even C1 have a much harder time handling flat values, possibly leading to performance regressions—an aspect to consider when maintaining good startup times.

Make sure to check the JVMLS 2025 playlist.