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:

1 Like

@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.


The saga continues and it seems the “L-World Value Types” (renamed to inline types) is really the final proposal. Recently a seconds prototype (LW2) came out at the usual place:

New L-World description page:

What is not changed since the beginning is that inline types (value types) are identity-less and immutable. That allows VM to switch between boxed and unboxed representation of an inline type without change in semantics. Therefore inline types can be directly (i.e. without boxing) put into registers, allocated on stack, returned via stack, copied, etc

Generics over inline types are still in flux (and not optimized), but non-generic code using inline types (without indirect i.e. nullable types that use syntax like SomeInlineType?) should yield high performance already.


thanks for the continued updates @tarsa!

No problem. I keep an eye on it out of curiosity.

Recently semi-official (?) benchmarks were posted on Valhalla mailing list: They show significant performance improvements already, but the downside is that value types in generics are still not supported so a lot of code is auto-generated. There’s an explicit note at the end:

It’s crucial to get specialized codegeneration for each inline class used for sorting. Without specialization generic objectified version will kill all benefits obtained by data locality. Right now C2 is able to provide such specialization only with methods inline. TimSort code is large enough not be inlined. Taking this into consideration indexed sort looks more prefferable, because of inline types are localized to relatively small top method.

IIUC what the JVM guys are fighting right now is performance regression for acmp bytecode instruction: IIUC the difficulty lies in the fact that if two value class instances have the same contents and compare the same using Java’s == (or Scala’s eq which compiles down to the same instruction) then boxes of those two values class instances must also compare true using the same operator. This adds significant overhead to something what was a simple reference equality check, so JIT compiler must be improved to reduce that overhead. Boxing happens when assigning a value class instance to a variable of type Object or some interface that the value class implements. In other words - there should be no observable identity of a value class instance, even when boxed. At least that’s what it looks to me.

PS: remember that they changed terminology from value classes to inline classes.