Vladimir V. Ivanov

Thanks for the review, Vladimir. Anybody else planning to review? Otherwise, I'll push it tomorrow.

Thanks for the review, Andrew. /integrate

Isn't it an illustration of a more general problem we have with native code where it can mess with FP environment at any time? We already have similar problems with...

> Note also that this specific problem is triggered by dlopen itself, because certain libraries might have some "bad" (from the perspective of JVM) initialization code. ... and it leads...

> The problem is that this bug is very insidious: the user probably doesn't know that there's anything wrong, and almost certainly has no idea that it's anything to do...

FTR I did an exercise in source code archeology and here are my findings. The origin of `AlwaysRestoreFPU`-related code (both in x86-32 and arm-specific code) can be traced back to...

Some additional info to consider: the library modifies only MXCSR register and `-XX:+RestoreMXCSROnJNICalls` makes the test to pass. ``` $ objdump -D libfast-math.so ... 0000000000000560 : 560: f3 0f 1e...

On non-windows x86-64 the JVM saves/restores (and adjusts if needed) MXCSR inside call stub as mandated by the ABI: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L262-L273 x87 is not used in x86-64-specific code anymore, so x87-specific...

So, IMO the discussion boils down to how we want a misbehaving native library to be handled by the JVM. The ABI lists MXCSR as a callee-saved register, so there's...

Thanks for the reviews, Roland and Tobias. hs-comp-stress and hs-precheckin-comp testing passed. /integrate