Why does Math.sin() delegate to StrictMath.sin()?

Question

I was wondering, why does Math.sin(double) delegate to StrictMath.sin(double) when I\'ve found the problem in a Reddit thread. The mentioned code f

Answer 1

I'll try to wrap up the entire discussion in a single post..

Generally, Math delegates to StrictMath. Obviously, the call can be inlined so this is not a performance issue.

StrictMath is a final class with native methods backed by native libraries. One might think, that native means optimal, but this doesn't necessarily has to be the case. Looking through StrictMath javadoc one can read the following:

(...) the definitions of some of the numeric functions in this package require that they produce the same results as certain published algorithms. These algorithms are available from the well-known network library netlib as the package "Freely Distributable Math Library," fdlibm. These algorithms, which are written in the C programming language, are then to be understood as executed with all floating-point operations following the rules of Java floating-point arithmetic.

How I understand this doc is that the native library implementing StrictMath is implemented in terms of fdlibm library, which is multi-platform and known to produce predictable results. Because it's multi-platform, it can't be expected to be an optimal implementation on every platform and I believe that this is the place where a smart JIT can fine-tune the actual performance e.g. by statistical analysis of input ranges and adjusting the algorithms/implementation accordingly.

Digging deeper into the implementation it quickly turns out, that the native library backing up StrictMath actually uses fdlibm:

StrictMath.c source in OpenJDK 7 looks like this:

   #include "fdlibm.h"
   ...
   JNIEXPORT jdouble JNICALL
   Java_java_lang_StrictMath_sin(JNIEnv *env, jclass unused, jdouble d)
   {
       return (jdouble) jsin((double)d);
   }

and the sine function is defined in fdlibm/src/s_sin.c refering in a few places to __kernel_sin function that comes directly from the header fdlibm.h.

---

_{While I'm temporarily accepting my own answer, I'd be glad to accept a more competent one when it comes up.}

Answer 2

The question assumes that the JVM actually runs the delegation code. On many JVMs, it won't. Calls to Math.sin(), etc.. will potentially be replaced by the JIT with some intrinsic function code (if suitable) transparently. This will typically be done in an unobservable way to the end user. This is a common trick for JVM implementers where interesting specializations can happen (even if the method is not tagged as native).

Note however that most platforms can't simply drop in the single processor instruction for sin due to suitable input ranges (eg see: Intel discussion).

Answer 3

Why does Math.sin() delegate to StrictMath.sin()?

The JIT compiler should be able to inline the StrictMath.sin(a) call. So there's little point creating an extra native method for the Math.sin() case ... and adding extra JIT compiler smarts to optimize the calling sequence, etcetera.

In the light of that, your objection really boils down to an "elegance" issue. But the "pragmatic" viewpoint is more persuasive:

• Fewer native calls makes the JVM core and JIT easier to maintain, less fragile, etcetera.

• If it ain't broken, don't fix it.

At least, that's how I imagine how the Java team would view this.

Answer 4

Math API permits a non-strict but better-performing implementations of its methods but does not require it and by default Math simply uses StrictMath impl.