On 10/13/22 19:13, Vladimir Ivanov wrote:
On Thu, 13 Oct 2022 07:47:20 GMT, Andrew Haley <a...@openjdk.org> 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.
I don't know anything about what we experienced before. In any case,
I'm not sure that precedent applies here: the problem is that there
are shared libraries in use which break IEEE semantics. This is
an insidious bug, and my proposed fix costs almost nothing.
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?
My patch is not in any way x86_64-specific. At present it is Linux-specific,
but I have my doubts that it should be.
$ 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
x86-32 has a very specific problem: its default floating-point precision is
AFAIK extended float, which does not meet Java specs. Also, restoring the
FPU after every JNI call is expensive.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
