BT

Your opinion matters! Please fill in the InfoQ Survey!

Design of Java Value Types Makes Progress

| by Ben Evans Follow 13 Followers on Nov 30, 2017. Estimated reading time: 3 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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:

  • vdefault which produces the default instance of a given value class
  • withfield which 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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT