RFR: JDK-8320892: AArch64: Restore FPU control state after JNI [v3]

Andrew Haley aph at openjdk.org
Tue Dec 5 13:42:39 UTC 2023


On Tue, 5 Dec 2023 11:37:48 GMT, Tom Shull <duke at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix thinko
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4439:
> 
>> 4437:     // don't want non-IEEE rounding modes or floating-point traps.
>> 4438:     bfi(tmp1, zr, 22, 4); // Clear DN, FZ, and Rmode
>> 4439:     bfi(tmp1, zr, 8, 5);  // Clear exception-control bits (8-12)
> 
> (Related to both this PR and https://github.com/openjdk/jdk/pull/16637) 
> 
> Shouldn't also explicit flushing inputs to zero, i.e. when AH:FIZ is (1:1), be protected against?
> 
> Also, is it necessary to clear DN? When looking at the spec, I think this should be allowed.

> (Related to both this PR and #16637)
> 
> Shouldn't also explicit flushing inputs to zero, i.e. when AH:FIZ is (1:1), be protected against?

I've avoided touching ArmV8.7 ALT_FP, but you might be right. AH:FIZ are both RES0, so it is safe to do so.

> Also, is it necessary to clear DN? When looking at the spec, I think this should be allowed.

I think it's wise to clear DN. We save and restore all of the FPCR at entry to Java, clearing DN, and it's not unreasonable to expect a JNI call not to mess with FPCR. Also, I think replacing NaN payload bits with the default NaN is pointless, and violates the principle of least surprise if not the spec of `longBitsToDouble`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16851#discussion_r1415629993


More information about the hotspot-dev mailing list