IEEE 754 exceptions and Java Virtual Machine

[David G. Hough at validgh]

I just learned something of interest in our ongoing Java discussion.   I'd
proposed that Java needed some efficient method for supporting detecting
the five IEEE 754 exceptions,
at least in basic blocks of code, and I'd supposed that since
almost all Java implementations are on systems that support IEEE 754 in
hardware, this would not be a big deal to add.    I hadn't thought about the
fact that since the facility is not in the language, it's not in the Java
Virtual Machine either, and therefore might not be implemented at all in
new Java Virtual Machines implemented in hardware, or in software on systems
with no floating-point hardware.    This would be bad news, I think, from
the point of view of supporting scientific computation.   Sometimes the
most efficient program is one that computes as fast as possible and traps
out to do something else if something bad happens; sometimes it's best just
to compute as fast as possible to the end and then check accrued exception
flags and do something else if something bad happened.   Possible syntax
such as 
	try { a = b * c ; } catch (overflow) {  a = 3.0 ;}
that one might propose adding to the language reflects such usages.

So I think JVM implementors would do well to make sure the IEEE 754 exception
flags at least are maintained through floating-point operations in the JVM,
and give thought to hardware mechanisms for reading and writing those flags
to support possible future language extensions.

If asynchronous
trapped IEEE 754 exceptions were treated as deterministically as other Java
exceptions, stopping execution precisely at the point the exception arose,
then that would be quite an advance in debuggability since there
would be no uncertain side effects when exceptions, but it would cost a lot
in execution time - far more than other issues we have discussed.   Just
supporting the flag model means that the whole computation in the try {}
would proceed until it finished and then the flags would be checked 
synchronously, at no special cost in execution time of the block.

Supporting  detecting exceptions in external functions within a try {}
raises lots of system issues and so might be much more expensive to support
well.

In contrast, the value of supporting dynamic IEEE rounding modes in the Java
Virtual Machine seems much less to me.    
Static rounding modes suffice for interval arithmetic.

The overall issue is how possible future directions for Java can
be explored.   Especially in the numerical area,
I think academic projects to explore language and JVM 
extensions should be encouraged, with the understanding that perhaps none
will necessarily be adopted.