java-valhalla-project
Java Valhalla Project
1. Overview
2. Motivation and Reasons for the Valhalla Project
In one of his talks, Brian Goetz, Java language architect at Oracle, said one of the main motivations for the Valhalla Project is the desire to adapt the Java language and runtime to modern hardware. When the Java language was conceived (roughly 25 years ago at the time of writing), the cost of a memory fetch and an arithmetic operation was roughly the same.
Nowadays, this has shifted, with memory fetch operations being from 200 to 1,000 times more expensive than arithmetic operations. In terms of language design, this means that indirections leading to pointer fetches have a detrimental effect on overall performance.
Since most Java data structures in an application are objects, we can consider Java a pointer-heavy language (although we usually don’t see or manipulate them directly). This pointer-based implementation of objects is used to enable object identity, which itself is leveraged for language features such as polymorphism, mutability and locking. Those features come by default for every object, no matter if they are really needed or not.
Following the chain of identity leading to pointers and pointers leading to indirections, with indirections having performance drawbacks, a logical conclusion is to remove those for data structures that have no need for them. This is where value types come into play.
3. Value Types
The idea of value types is to represent pure data aggregates. This comes with dropping the features of regular objects. So, we have pure data, without identity. This means, of course, that we’re also losing features we could implement using object identity. Consequentially, equality comparison can only happen based on state. Thus, we can’t use representational polymorphism, and we can’t use immutable or non-nullable objects.
Since we don’t have object identity anymore, we can give up on pointers and change the general memory layout of value types, as compared to an object. Let’s look at a comparison of the memory layout between the class Point and the corresponding value type Point.
The code and the corresponding memory layout of a regular Point class would be:
final class Point {
final int x;
final int y;
}
On the other hand, the code and corresponding memory layout of a value type Point would be:
value class Point {
int x;
int y
}
This allows the JVM to flatten value types into arrays and objects, as well as into other value types. In the following diagram, we present the negative effect of indirections when we use the Point class in an array:
On the other hand, here we see the corresponding memory structure of a value type Point[]:
It also enables the JVM to pass value types on the stack instead of having to allocate them on the heap. In the end, this means that we’re getting data aggregates that have runtime behavior similar to Java primitives, such as int or float.
But unlike primitives, value types can have methods and fields. We can also implement interfaces and use them as generic types. So we can look at the value types from two different angles:
-
Faster objects
-
User-defined primitives
As additional icing on the cake, we can use value types as generic types without boxing. This directly leads us to the other big Project Valhalla feature: specialized generics.
4. Specialized Generics
When we want to generify over language primitives, we currently use boxed types, such as Integer for int or Float for float. This boxing creates an additional layer of indirection, thereby defeating the purpose of using primitives for performance enhancement in the first place.
Therefore, we see many dedicated specializations for primitive types in existing frameworks and libraries, like IntStream<T> or ToIntFunction<T>. This is done to keep the performance improvement of using primitives.
So, specialized generics is an effort to remove the needs for those “hacks”. Instead, the Java language strives to enable generic types for basically everything: object references, primitives, value types, and maybe even void.
5. Conclusion
We’ve taken a glimpse at the changes that Project Valhalla will bring to the Java language. Two of the main goals are enhanced performance and less leaky abstractions.
The performance enhancements are tackled by flattening object graphs and removing indirections. This leads to more efficient memory layouts and fewer allocations and garbage collections.
The better abstraction comes with primitives and objects having a more similar behavior when used as Generic types.
An early prototype of Project Valhalla, introducing value types into the existing type system, has the code name LW1.
We can find more information about Project Valhalla in the corresponding project page and JEPs:
