Matlab's Loss is Nobody's Gain

[David Chase]

>Well, that depends.  A class with the same name could be evolved over
>time (or replaced by another version) without any change in the client
>code (dynamic linking is the norm in Java).  Different VM providers
>might also include classes with the same name but slightly different
>semantics.

Could happen, but shouldn't.  There's a trademark that Sun could
enforce.  We could write "String" with a better hash function, but
we should not call it "java.lang.String".

[explanation of complex/imag deleted.]

Thanks.

>> p. 56
>> The paper needs a better example to justify access
>> to
   dynamically scoped  <- omitted from original message, sorry
>>      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:
>
>[use a special rounding mode debugger or hack the bytecode]

>Sometimes taking a one or two order of magnitude performance hit is
>not acceptable.

This is still not compelling; if anything, it looks like
you are straining to make the claim.  Every language
I've ever used contains design decisions that are "sometimes
unacceptable".  The tradeoff here is between a debugging
tool (that could be provided via a non-standard interpreter
or VM, not necessarily a slower one) and including
behavior in the standard that makes it not possible to
say exactly what a particular piece of (floating point)
code means.  This complicates tools and testing, and
might invalidate optimizations done by existing Java
compilers and VMs.  Again, note that I have no problem
with lexically-scoped changes to FP behavior, only with
dynamically scoped changes that affect code that was
neither written nor compiled nor tested to expect such
a change.

We may have different views of programs.  In a sufficiently
large system, it is prudent to assume that someone working
on it somewhere codes liked a sociopathic martian on drugs,
and someone else has this some opinion of you.  Good fences
make good neighbors.  Lexical scope is a good fence,
dynamic scope is not. 

>> 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.
>
>As listed in the first edition of "The Java(TH) Programming Language,"
>one situation where native methods are appropriate is where "an
>application must use system-specific features not provided by Java
>classes."  IEEE 754 sticky flags and rounding modes are such features.

And you can fiddle with them while you are executing
native code.  Once you're back from native code, it is back to
Java semantics, as specified.  You should not rely on this
bug to continue to exist, because it is a bug.  Why is it
a bug?

 - the JNI spec does tell you some things that should not
   be done, else undefined behavior will result.

 - changing the FP modes is not in that list (perhaps
   it is incomplete, but all we've got to go on is
   what Sun wrote).

 - normally, Java should continue to execute as Java
   after a call to JNI returns, including all FP
   operations.

 - therefore, a Java VM *should* ensure that the FP
   modes are set properly for Java execution after
   any JNI call returns (because the spec does not
   tell you to expect otherwise).

As a compiler writer, I really don't have any choice
but to interpret the spec in the most legalistic
manner possible.  In this case, I conclude that
the rounding modes should be set back.  That Sun missed
this in their implementation is not too surprising,
since I missed it myself until I read about the trick,
and in the past Sun has failed to reset/restore
rounding modes across exec and in longjmp.  That
this could escape notice so many times (and recall
that I already knew about Sun's two previous bugs,
yet still missed it here) seems like a great reason
to avoid dynamically modified FP rounding.

Also, native calls could be relatively slow in some
systems, depending upon their design goals (there's
many tradeoffs you could make in a Java runtime).

It would be better to specify the bytecodes that you want,
probably with appropriate dataflow restrictions for the VM
corresponding to lexical scope in the original program.

David Chase
NaturalBridge LLC