Floating Point and Arithmetic Changes for Java SE Lnguage
brian.goetz at oracle.com
Thu Mar 8 21:46:09 UTC 2018
> 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.
More information about the core-libs-dev