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
