RFR: 8295159: DSO created with -ffast-math breaks Java floating-point arithmetic [v7]

[David Holmes]

On 26/10/2022 1:02 am, Andrew Haley wrote:
> On Tue, 25 Oct 2022 14:46:57 GMT, Florian Weimer <fweimer at openjdk.org> wrote:
> 
>> Sorry, I feel like this has gone a bit off track. It started as some hardening for `loadLibrary`, but now it's about making all JNI calls a bit slower? Is there any data to suggest that this is necessary?
>>
>> Would it be possible to capture some FPU state evidence in crash dumps, as an alternative?
> 
> Really? The problem is that when certain libraries are loaded, we get silently corrupted results. Vladimir Ivanov pointed out that the weakness applies to any JNI call, and we wondered if it might be possible to make the workaround so cheap that we could leave it on by default. IMVHO we probably could: the additional overhead is about 1-1.5ns. The only way to measure it is carefully written tests against a JNI call that does nothing.

The loadlibrary issue is a concrete issue with a simple and localised 
solution. The extension to "well this could potentially happen on any 
JNI call if it messed with FP state" is a theoretical problem that has 
always been there. If it were free to fix then sure lets be super 
conservative, but it seems to me we are going to penalize everyone (and 
we just went to some effort to produce extremely fast trivial JNI calls) 
to account for something nobody has any evidence is happening - and if 
it did happen then the library being used should be fixed. I don't see 
why we should make everyone pay for this "just in case". At most an 
expanded -Xcheck:jni check for FP-state manipulation, with an 
enhanced/fixed RestoreMXCSROnJNICalls is in order IMVHO.

YMMV.

Cheers,
David
-----

> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/10661