Re: Calling standard native function
On 2/19/2011 12:22 PM, Andreas Leitgeb wrote:
Eric Sosman<esosman@ieee-dot-org.invalid> wrote:
The JIT might do this no matter what the supposed
Math.foo() source looks like
You mean, if I were to modify my Java-installation's rt.jar and
replaced Math.class by an April1st-version, which implemented "pow()"
by redirecting to atan2(), then the jit could still change invocations
to the processor's "dpow"-instruction (whatever its actual name) ?
That's my understanding. Besides, if you've somehow injected
foreign classes into the Java core, you're not running Java any more
but some Java-ish impostor. Java's guarantees therefore no longer
hold, and there's no telling what might happen. (Imagine a similar
redirect of System.out.println() to System.err.printf(), for example.)
and might give different results before and after a
calling method gets JITted, and so on.
This admittedly surprises me. I was (of course) prepared to expect a
different result from StrictMath, but not a different result possibly
between two iterations of the same loop...
I don't know whether this actually occurs, but I don't see anything
in the java.lang.Math Javadoc that forbids it. And it's certainly a
plausible scenario: Interpret the byte code for the first N iterations,
then get JITted to a hardware instruction with slightly different
behavior -- and then maybe get un-JITted when a new class is loaded
and the method can't be inlined quite so easily ...
Perhaps there's something in the JLS or JVMS that nails things down
more precisely; I haven't looked.
I naively would have expected the non-JIT-compiled version to invoke
the same math-processor opcodes, just maybe wrapped in subroutines,
which the JIT would inline.
(Just trying to make sure I wasn't misunderstanding what you said)
You've understood me correctly. Whether I myself am correct is
a different question! ;-)
--
Eric Sosman
esosman@ieee-dot-org.invalid