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 ( https://mreinhold.org/blog/forward-faster ) 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 ( Newtype - HaskellWiki ) and the only reason is to avoid boxing. Java’s Value Types are also about avoiding boxing so there’s a crucial overlap.
Update:
I’ve clicked wrong “reply” button. Sorry about that.
@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.
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.
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).
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.
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: http://jdk.java.net/valhalla/
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.
Recently semi-official (?) benchmarks were posted on Valhalla mailing list: LWords value arrays sorting study 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: http://cr.openjdk.java.net/~skuksenko/valhalla/reports/acmp/JPG-acmpValhallaPerformanceSummary-220819-1649-56.pdf 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.