Matlab's Loss is Nobody's Gain

[David Chase]

At 04:55 PM 9/2/98 -0700, David G Hough at validgh wrote:
>A recent Java paper is at 
>
>http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

Comments:

Note the distinction between "Java" changes and
"JVM" changes.  I think changes to the VM are regarded
as more costly (certainly by me, since I'm working
on one).

p.11 I don't buy the "more than one" Complex
class claims.  Or rather, that there will be no
problem of confusion, unless the three Complex
classes are made interchangeable behind either
an abstract base class or an interface (which
would make them slower and difficult to inline
and optimize).  One complex class might be
called java.lang.Complex, another might
be org.fsf.lang.Complex, yet another could be
edu.uc.berkeley.kahan.Complex.  Code written to
use one would not (and could not) use another
unless its source code were modified.  I do
not worry that my code will fail because the
FSF might write their own org.fsf.lang.String,
because my code makes explicit reference to
java.lang.String.

p.11 Given the level of detail provided later for
things like rounding errors, I'd like to see a
little more explanation of the difference between
"x + y*I" and "(x,y)".  My first reaction to the
claims of "extra costs" for "x + 0*I" is that they'd
be optimized away (just as some compilers will
optimize away the upper 32 bits of a "long long"
if it is unused) but then I recall NaNs and Infs
and the difficulty of proving that they do not
occur as inputs to various operations.

p.15, the same.  What is it about (x,y) versus
x+y*I that produces these anomalies?  To me (a
compiler backend person) these differences appear
to be mere syntactic sugar; there must be something
peculiar in the way that Fortran systematically
translates the complex operations.

p. 16
"Linguistically legislated exact reproducibility is
 unenforceable" ????
What about Sun's Java trademark?  They can, in theory,
block anyone from using the word "Java" who does not
conform exactly.  "J++", of course, is not trademarked
by Sun.

p. 20, quibbling about use of the term "exception"
in Java not matching IEEE-754.  This is petty and
distracting.  Java's use of the word follows
Modula-3 and C++, which follow Modula-2+, which
follows Cedar, which follows Mesa, which probably
got it from somewhere else.

p.45
The recommendations regarding use of "double" for
intermediate results and default choice of double-arg
routines except where explicitly cast can be implemented
without breaking VM compatibility; that is, different
bytecodes can be generated from source.  I think this
distinction matters to Sun, the paper should make the point
explicitly that it does not require any VM changes.

p.47
However, the speed claims for use of "double" as an
intermediate value not slowing down Intel are not
correct (as near as I can tell, without making other
changes to the language).  The reason for this is that
current bit-for-bit Java-equivalent evaluation of
double multiplication and division on Intel is much
more expensive than the same for "float"; in the case
of double, it is necessary to detect and correct for
the doubly-rounded denorm result case, but for float
it is sufficient (?) to merely load, perform the
double op, and store (I'm almost certain this is
correct for multiplication, and I think it works
for division).  Replacing float ops with double
ops will slow programs down on Intel.

p. 56
The paper needs a better example to justify access
to directed rounding modes.  Debugging tools are
often extralingual, which is another way of saying
that debugging tools need not be specified as part
of the language.  Support for this directed rounding
debugging trick can be added either:

- by a debugging interpreter with support for special
  calls to tweak the rounding modes.

- by a byte-code translator that replaces arithmetic ops
  with calls to directed-rounding routines.

These approachs may impose terrific slowdowns, but
that is not out of the ordinary for debugging tools,
which may be interpreters (CenterLine's CodeCenter and
ObjectCenter) or may insert source-level checking
(Parasoft's Insure++ and CenterLine's C++Expert).

>From the point-of-view of someone who prefers to
view programs as having a single defined behavior
(and not a collection of behaviors parameterized
by a collection of global knobs) I've never quite
understood the use of mode bits to control FP rounding;
the DEC Alpha approach makes much more sense to me.
I can see where it might be helpful to modify it in
a lexical sense (I thought that Borneo worked
this way, perhaps I am wrong) but dynamically modifying
flags for a called piece of code that I did not write
and probably do not understand seems dubious unless
I am looking for bugs (in which case, I use a debugging
tool).  And yes, I realize that because of threads
and finalization, Java's already a little bit
pregnant with respect to platform-specific behavior.

Also, Borneo's implementation strategy (native calls
that tweak the rounding modes) is unlikely to work in
all JVM's; upon hearing about Borneo's trick, my
reaction was that there was another piece of machine
state that I need to remember to reset upon return from
a native call. In other words, Borneo exploits a bug in
current Java implementations.  (I'm not doing this to be
perverse, I'm implementing Java in conformance with
Sun's spec, which includes continuing to run in the
proper fashion after native calls.  Not my job to
improve the spec, no matter how wonderful my ideas
might be.)

p.75 Again, note the distinction between Java source
compatibility and Java VM compatibility.  The changes
at the VM level from 1.0 to 1.1 to 1.2 have been
relatively minor (it depends somewhat on the VM
implementation strategy, but in my experience there
were no changes from 1.0 to 1.1, and only the addition
of soft/weak/phantom references to 1.2, which require
more work in the garbage collector).

Some of the proposed changes also require VM changes,
if they are to be implemented efficiently.  Class-based
implementations of Complex and Imaginary are unlikely
to run with acceptable speed; those types will need to
be added as primitives to the language.  The same goes
for long double and indigenous.

Because of the Java/JVM split, relaxing associativity
is likely to be tricky to specify in a way that is
useful, safe, and efficient.  Compilation from Java
to bytecodes is (currently) not machine-specific, so
there's little machine-specific reassocation that
can occur here.  On the other hand, all the lexical
structure present at the source level is lost at
the bytecodes, so a bytecode-to-native compiler
(whether batch or better-late-than-never) will not
see the boundaries across which reassociation should
not occur.  (There's no distinction between temporaries
and variables at the bytecode level, either.)

I'll get myself a copy of the Borneo spec to
see how many of my questions about VM changes are
answered there.

David Chase
NaturalBridge LLC