Floating Point and Arithmetic Changes for Java SE Lnguage

[Brian Goetz]

> One of the use-cases for the value type changes being worked on in 
> Project Valhalla is lower-overhead for numerical types, such as 
> BigDecimal and BigInteger and potential classes like complex, etc. 
> IMO, it would also be reasonable to have syntactic support for 
> operators on such types.
>
> There are no prospects for a fundamental redefinition of the 
> floating-point semantics of the Java language and VM. It is possible a 
> faster and looser mode will be defined at some point, but altering the 
> default is extremely unlikely. Long-term, decimal-based arithmetic 
> (and other kinds of arithmetic) may get better support as a 
> consequence of the features in Valhalla. Filing additional bugs or 
> additional emails to this alias will not change any of this or make it 
> happen faster.

For those who are not aware of what's going on in Project Valhalla...

There is an obvious gap between primitive and reference types in Java.  
The primitive types we have are fixed and we effectively cannot make 
more.  This makes many people sad, as they would like to have their 
favorite numeric type built into the platform.  As Guy Steele taught us 
in Growing a Language, adding every possible numeric type into a 
language that some user might find useful is a losing game; you want to 
be able to write these as ordinary user-written libraries instead.

Java makes it easy to write libraries, but classes have an inherent 
performance cost, because of their pervasive object identity (even when 
it is not actually needed, in so-called "value-based classes.")  I can 
easily write a complex or unsigned 64 bit int or 37-bit BCD numeric 
class, and give it all the operations I want, but because instances of 
objects are stored in the heap, they will come at a performance 
disadvantage, in space and time, to primitives.

Project Valhalla's solution is: value types.  Value types are like 
classes in that they can have fields, methods, constructors, type 
variables, implement interfaces, and many of the other characteristics 
of a class, but are like primitives in that they are laid out flat and 
dense in memory -- no object header, no indirection.  So an array of 
Complex would be laid out re/im/re/im, rather than as a sequence of 
pointers to [ re, im ] boxes.  "Codes like a class, works like an int."

Value types let us write new numeric (and other) types as library 
classes, and get the performance characteristics of primitives. Users 
will be able to write their 37-bit BCD classes as plain library code, 
and will not have to beg the Java maintainers for fundamental (and 
effectively impossible) changes to satisfy their specific numeric needs.

Project Valhalla has been rolling for a few years, and will likely go 
for a few more until we reach the point where this is practical -- and 
more after that before value types can fit cleanly into the generic type 
system.  Its a big project, into which Oracle (and IBM, and Red Hat) 
have already made substantial investments.   We invite others who have 
the requisite skills to join us; right now most of the work is going on 
in the interpreter and JIT.  The language work will follow, and the 
library work will follow that.