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

[Vladimir Ivanov]

Vladimir K.,

You are right, I overlooked that peculiarity.
I've filed 8013931 [1] to track the issue with j.l.Math instrumentation.

Best regards,
Vladimir Ivanov

[1] https://jbs.oracle.com/bugs/browse/JDK-8013931

On 4/30/13 7:33 PM, Vladimir Kozlov wrote:
>  > 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