Valhalla and Improving Value Types


If JDK 10 takes another 3.5 years, I think there’s a decent chance it will have Valhalla. If it comes out next year, not so much.

(It was not clear to me whether the faster release schedule for Java was meant to suggest multiple minor versions, e.g. Java 9.1, 9.2, etc., or “full” releases such as 10 and 11.)

Regardless, I don’t think opaque types and value types have quite the same goals, and I think opaque types still provide significant value even in the (hypothetical) presence of value types.


FWIU the proposed Java release train would be very similar to Ubuntu release schedule. Ubuntu releases every 6 months and 1 out of 4 releases is a LTS. In proposal ( ) Java would be released also every 6 months but only 1 out of 6 releases would be a LTS. Also the Ubuntu naming scheme is considered for adoption:

I’ve skimmed through explanation of why newtype was added to Haskell ( ) and the only reason is to avoid boxing. Java’s Value Types are also about avoiding boxing so there’s a crucial overlap.

I’ve clicked wrong “reply” button. Sorry about that.


Official early access builds for minimal value types (from Project Valhalla) are available here:

BTW: Graal will be included as an experimental JIT compiler in Java 10:

Java 10 will be released on 20th March 2018: but still won’t be a LTS release:


@tarsa Do you know if that EAP only implements the Value Types draft proposal suggested by John Rose et al? Or have there been any significant updates on the implementation?

Las time I checked the proposal made several naive assumptions and was limited in several ways.


No idea, but here’s quote from announcement

Keep in mind that “Minimal Value Types” (MVT) is an experiment, much of
external facing for Value Types will be changing. Case in point: “LWorld
prototype - initial brainstorming goals/prototyping steps” [1], shows a
direction whereby Value Types are more compatible with existing
bytecodes, rather the numerous “v-byte-codes” found under the covers of
MVT. That said, much of the internal VM representation, like layout and
JIT scalarization of value types likely remains.

There’s also JVMS update posted on from June 2017.


Project Valhalla “L-World Value Types” Early-Access Build is available:

Value classes are fully immutable (even in constructor they work like copy-on-write structures) and final (so cannot be abstract or extended) and cannot extend other classes (only interfaces).

More info is here: e.g.

Value Types may be referred to by the same “L-Type” descriptors the VM has always operated on:

  • May implement interfaces with value types
  • May pass a value type as a java.lang.Object, or an interface through existing APIs

I assume that boxing to Object or interface types would have special boxing elimination heuristics built into VM to reduce the overhead of such boxing, at least when passing individual instances through method calls.

Command line options are here:
Some looks like useful ones, e.g.:

Flag Description
-XX:+PrintEliminateAllocations Non-product builds: Print out when allocations are eliminated
-XX:+PrintEscapeAnalysis Non-product builds: Print results of escape analysis (e.g. if you believe boxing was not eliminated)

“L-World Value Types” looks like it’s their final design. Now the work is on addressing limitations and implementing missing features.