Some of j.l.Math::* functions can't be redefined (dynamically instrumented): is it expected?

[Vladimir Kozlov]

 > Shouldn't StrictMath counterparts be intrinsified instead? At least,
 > when class redefinition is allowed.

No, we can't do that. Think about StrictMath as reference implementation 
in java which produces exactly the same results on all platforms. Where 
non-strict math is for using hardware instructions to get best 
performance and may produce not the same result (but with variation not 
bigger then in java specification).

"Unlike some of the numeric methods of class StrictMath, all 
implementations of the equivalent functions of class Math are not 
defined to return the bit-for-bit same results. This relaxation permits 
better-performing implementations where strict reproducibility is not 
required.

By default many of the Math methods simply call the equivalent method in 
StrictMath for their implementation. Code generators are encouraged to 
use platform-specific native libraries or microprocessor instructions, 
where available, to provide higher-performance implementations of Math 
methods. Such higher-performance implementations still must conform to 
the specification for Math."

http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html

Vladimir K

On 4/30/13 6:17 AM, Vladimir Ivanov wrote:
> Hi,
>
> I stumbled upon a fact that some of Math.* functions, though they are
> written in Java, can't be instrumented/redefined (using
> j.l.i.Instrumentation or JVMTI RedefineClasses).
>
> Looking at the code, I see that the interpreter handles such functions
> specially:
> src/share/vm/interpreter/interpreter.cpp:
> ...
> 184 AbstractInterpreter::MethodKind
> AbstractInterpreter::method_kind(methodHandle m) {
> ...
> 228   switch (m->intrinsic_id()) {
> 229     case vmIntrinsics::_dsin  : return java_lang_math_sin  ;
> ...
>
> but
>
> src/share/classes/java/lang/Math.java:
> ...
> 138    public static double sin(double a) {
> 139        return StrictMath.sin(a); // default impl. delegates to
> StrictMath
> 140    }
> ...
>
> and
>
> src/share/classes/java/lang/StrictMath.java:
> ...
> 110     public static native double sin(double a);
> ...
>
> Shouldn't StrictMath counterparts be intrinsified instead? At least,
> when class redefinition is allowed.
> Best regards,
> Vladimir Ivanov