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

[Thomas Stuefe]

On Thu, 26 Oct 2023 14:17:02 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Duh

This looks good to me.

One suggestion: to reduce code duplication and to make the code a bit safer against accidental returns prior to fesetenv, I would have used a mark object like this:


struct FenvResetMark {
  fenv_t _fenv;
  FenvResetMark()   { fegetenv(&_fenv); }
  ~FenvResetMark()  { fesetenv(&_fenv); }
};


and would have placed it above dlopen calls. Up to you.

---

About the dlopen calls in the JDK, at SAP we were faced with similar problems for other libc APIs (how to apply a fix to all of them). Some of these issues we solved by redirecting all calls to libjvm. Others we solved manually, in-place, with a lot of duplication. None of these sound appealing, but I like the redirect-to-libjvm route somewhat, if Oracle can be convinced.

A third option would be to use an interposition library with LD_PRELOAD. One that overwrites dlopen and redirects to the real one. I don't see this to be a practical solution but it may be valid for testing.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/10661#pullrequestreview-1699974743