Project Valhalla: Goals

[Brian Goetz]

I've heard a number of people describe Valhalla recently as being 
"primarily about performance".  While it is understandable why people 
might come to that conclusion -- many of the motivations for Valhalla 
are, in fact, rooted in performance considerations -- this 
characterization misses something very important.  Yes, performance is 
an important part of the story -- but so are safety, abstraction, 
encapsulation, expressiveness, maintainability, and compatible library 
evolution.

The major goals of Valhalla are:

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

Let's take these in turn.

*1. **Align JVM memory layout behavior with the cost model of modern 
hardware. *

Java's approach of "(almost) everything is an object" was a reasonable 
match for the hardware and compilation technology of the mid-nineties, 
when the cost of a memory fetch and an arithmetic operation were of 
comparable magnitude.  But since then, these costs have diverged by a 
factor of several hundred. At the same time, memory costs have come to 
dominate application provisioning costs.  These two considerations 
combine to make the graph-of-small-objects data representation, which 
typical Java programs result in, suboptimal in both program performance 
and provisioning cost.

The root cause of this is a partly accidental one: object identity.  
Every object has an identity, but not all objects /need/ an identity -- 
many objects represent values, such as decimal numbers, currency 
amounts, cursors, or dates and times, and do not need this identity.  
This need to preserve identity foils many otherwise powerful optimizations.

Our solution for this is /value types/; value types are aggregates, like 
traditional Java classes, that renounce their identity.  In return, this 
enables us to create data structures that are /flatter/ (because values 
can be inlined into objects, arrays, and other values, just as 
primitives are today) and /denser/ (because we don't waste space on 
object headers and pointers, which can increase memory usage by up to 
4x), with a programming model more like objects -- supporting nominal 
substructure, behavior, subtyping, and encapsulation. /Codes like a 
class, works like an int./

If you view values as being "faster objects", you could indeed view this 
fundamental aspect of Valhalla as being primarily about efficiency.  But 
equally, you could view them as "programmable primitives", in which case 
it also becomes about better abstraction, encapsulation, readability, 
maintainability, and type safety.

Which is the real point -- that we need not force users to choose 
between abstraction/encapsulation/safety and performance.  We can have 
both.  Whether you call that "cheaper objects" or "richer primitives", 
the end result is the same.


*2. **E**xtend generics to allow abstraction over all types, including 
primitives, values, and even void.**
*
Generics are currently limited to abstracting only over reference 
types.  Sometimes this is merely a performance cost (one can always 
appeal to boxing), but in reality this not only increases the cost, but 
decreases the expressiveness, of libraries.

Methods like Arrays.fill() have to be written nine times; this is nine 
methods to write, nine methods to test, and nine methods for the user to 
wade through in the docs.

Real-world libraries like Streams often resort to hand-coded 
specializations like IntStream; not only is this an inconvenience for 
the writer, but was also a significant constraint in the design of the 
stream library, forcing some undesirable tradeoffs. And this approach 
rarely provides total coverage; users complain that we have IntStream 
and LongStream but not CharStream.  (For generic types with multiple 
type variables, like Map, the number of specializations starts to 
explode out of control.)  The functional interfaces introduced in Java 8 
are another consequence of the limitations of generics; because generics 
are boxed and erased, we had to provide a large number of 
hand-specialized versions (and still, not all the ones people want.)  
You don't need Predicate if you have can simply say Function<T, boolean> 
and not suffer boxing or erasure.

Everyone would be better off if we could write a generic class or method 
once -- and abstract over all the possible data types, not just 
reference types.  (This includes not only primitives and values, but 
also void.  Treating void uniformly is no mere "abstract all the 
things"; HashSet is based on HashMap, for implementation convenience, 
but suffers a lot of wasted space as a result; we could use a HashMap<T, 
void>.  And the XxxConsumer functional interfaces are really just 
Function<T, void> -- we don't need separate abstractions here.)

Being able to write things once -- rather than having an ad-hoc 
explosion of types and implementations (which often propagates into 
further explosion at the client site) -- means simpler, more expressive, 
more regular, more testable, more composible libraries.  Without giving 
up performance when dealing with primitives and values, as boxing does 
today.

Which is to say, again, just at the data-abstraction layer instead of 
the data-modeling layer: we need not force users to choose between 
abstraction/encapsulation/safety and performance.


*3. **Enable existing libraries -- especially the JDK -- to compatibly 
evolve to fully take advantage of these features.**
*
The breadth and quality of Java libraries is one of the core assets of 
the Java ecosystem.  We don't want people to have to replace their 
libraries to migrate to a value-ful world; nor do we want existing 
libraries to be "frozen in time." (Imagine if we did lambdas and 
streams, but didn't do default methods, that allowed the Collection 
classes to evolve to take advantage of them -- Collections would have 
instantly looked ten years older.) There should be a straightforward 
path to extending existing libraries -- especially core JDK libraries -- 
to supporting values and enhanced generics, in a way that makes them 
"look built in".  This may require additional linguistic tools to allow 
libraries to evolve while providing compatibility with older clients and 
subclasses that have not yet migrated.

Just providing these features for new libraries is not enough; if widely 
used libraries can't compatibly evolve to take advantage of this new 
world, they are effectively consigned to a slow death. This might be OK 
for some classes -- deprecating OldX and replacing it with NewX -- but 
only when uses of the OldX types aren't strewn through lots of other 
libraries.  That rules out starting fresh with Collections, Streams, 
JSR-310, and many other abstractions, without rewriting the whole JDK 
(and many third party libraries).  So instead, we have to provide a 
compatible path for such libraries (and their clients) to modernize.


So, to summarize: Valhalla may be motivated by performance 
considerations, but a better way to view it as enhancing abstraction, 
encapsulation, safety, expressiveness, and maintainability -- /without/ 
giving up performance.