On Wed, 12 Oct 2022 20:35:09 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
> Isn't it an illustration of a more general problem we have with native code > where it can mess with FP environment at any time? Yes. > We already have similar problems with MXCSR register and provide verification > logic (part of `-Xcheck:jni`) to catch modifications and support conditional > restoration of MXCSR register on x86_64. x86_32 validates x87 control word > when `-Xcheck:jni` is enabled. > > Should we do something similar here instead? 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. Saving and restoring the floating-point environment across dlopen() is a compromise between adding extra code at JNI callouts, which can be expensive, and shifting the burden to the user. ------------- PR: https://git.openjdk.org/jdk/pull/10661
