On Thu, 13 Oct 2022 07:47:20 GMT, Andrew Haley <[email protected]> wrote:
> 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 with JNI.
I'm still trying to grasp why the current problem is something different from
what we experienced before.
Some platforms (x86_32 and AArch32) provide a way to restore FP environment,
but it is turned off by default. Why x86_64 case is different, so it requires
the logic to be turned on by default? Does the same reasoning apply to those
platforms as well and we want to have `AlwaysRestoreFPU` turned on by default?
$ grep -r AlwaysRestoreFPU src/hotspot/
src/hotspot//cpu/x86/templateInterpreterGenerator_x86.cpp: if
(AlwaysRestoreFPU) {
src/hotspot//cpu/x86/sharedRuntime_x86_32.cpp: if (AlwaysRestoreFPU) {
src/hotspot//cpu/arm/sharedRuntime_arm.cpp: if (AlwaysRestoreFPU) {
src/hotspot//cpu/arm/templateInterpreterGenerator_arm.cpp: if
(AlwaysRestoreFPU) {
src/hotspot//share/runtime/globals.hpp: product(bool, AlwaysRestoreFPU, false,
\
-------------
PR: https://git.openjdk.org/jdk/pull/10661
