Project Valhalla with OpenJDK has posted a major update and has announced some initial, very early-stage design concepts for value types in the JVM.
The overall mission statement of the project is to be "a venue to explore and incubate advanced Java VM and Language feature candidates". Brian Goetz explains the major goals of the project as:
- Align JVM memory layout behavior with the cost model of modern hardware
- Extend generics to allow abstraction over all types, including primitives, values, and even void
- Enable existing libraries especially the JDK to compatibly evolve to fully take advantage of these features.
Up to and including version 9, Java only has two sorts of values - primitive types, and object references. To put this another way, the Java environment deliberately does not provide low-level control over memory layout. As a special case, this means that Java has no such thing as structs, and any composite data type can only be accessed by reference.
This memory layout pattern has been the way that major implementations of the Java platform have functioned for the last 20 years. It has the advantage of great simplicity, but comes with a number of performance tradeoffs - such as the fact that dealing with arrays of objects involves unavoidable indirections and attendant cache misses.
As a result, many performance-oriented programmers would like the ability to define types that can be laid out in memory more efficiency - value types.
These new types would also reduce overhead by removing the need for a full object header for each item of composite data. Removal of the object header would also remove the instance-specific metadata that all current Java objects have.
One consequence of this is that the object's identity would be lost, and values would be equal if and only if all their fields are equal. This would make values behave similarly to the primitive types - each copy of the value 42 does not have its own identity after all.
To accommodate this major change, some new bytecodes will need to be introduced, but currently it is believed that only two new opcodes would need to be added:
vdefaultwhich produces the default instance of a given value classwithfieldwhich produces a new value of a value type (and throws on a non-value)
Some existing bytecodes will also need some retrofitting to handle value types.
Above the VM level, work is also needed to allow the core libraries to evolve in a compatible manner - as it will now be necessary e.g. to have a method to test an Object variable to see if it actually contains a value object.
Beyond this simple conception of value types are some immediate further design questions. For example, whether value types can be used as type parameter values for generic types.
If not, then this would seem to greatly limit the usefulness of value types. Therefore, the design discussion of values types has always included the assumption that they will be valid as values of type parameters in an as-yet-unspecified enhanced form of generics.
Ongoing research in Project Valhalla has led to the following early stage design concept: That there should be three different kinds of JVM class and interface types at VM level:
- Reference types that represent references to an instance of a class that has an identity (or is null)
- Value types - that hold an instance of a value class that lacks identity
- Universal types - that can be either of the other two types
This raises the obvious question - "How should type information in existing class files be understood?"
That is, are the existing current object types in Java 9 class files actually considered to be reference types, or are they really universal types and it's simply the case that we've never seen an instance of a value class before?
The current design is still in the very early stages and is only a proposal that will not be fully baked for months, and may be years away from production readiness and shipping code.
Due to the changes to the release schedule, it is completely unknown which release of Java will eventually feature value types as a production feature.
The discussion and research continues on the Project Valhalla mailing lists, and readers who are comfortable with VM internals should start there for more details, with the understanding that the current work is a long way from being usable by most developers and is only at the prototyping stage.