RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v3]

[Gerard Ziemski]

On Thu, 18 Feb 2021 02:28:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Gerard,
> 
> I'm concerned by the general problem of encountering new bugs because we are running on an x64 emulation mode on ARM! Is there any way to detect this Rosetta environment?

We can detect if we are running under emulation using this code provided by Apple [https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment](https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment?language=objc#3616845)

> Is there a way to know from the hs_err file (we don't have one for this issue yet) that we executed under Rosetta?

One can infer such scenario by looking at the log under the _system_ section:

`OS:uname: Darwin 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21 00:06:51 PST 2021; root:xnu-7195.81.3~1/RELEASE_ARM64_T8101 x86_64`

We see **RELEASE_ARM64_T8101** type kernel running **x86_64** code, but we should detect this and report it to users directly. Filed a followup issue [JDK-8261966](https://bugs.openjdk.java.net/browse/JDK-8261966) to track it. Thank you for the bringing this point up!

> How will we track this bug on Apple's side, such that we can eventually remove this workaround?

I have filed the issue a while ago with Apple here [https://feedbackassistant.apple.com/feedback/8984455](https://feedbackassistant.apple.com/feedback/8984455), but please note that you probably need Mac developer account to be able to see it.

Apple has set the resolution of this issue as `Potential fix identified - For a future OS update`, but we will always need it for the already released macOS version.

> The workaround itself seems okay as far as it goes but what happens if native code triggers a real FPE_FLTINV that we will now treat as "div by zero"?

Excellent question. According to https://en.wikipedia.org/wiki/IEEE_754 invalid operation is `mathematically undefined, e.g., the square root of a negative number. By default, returns qNaN.` I will test this scenario out and report back...

Regardless though, we absolutely need this workaround for the time being, though we might want to use only in emulation environment.

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

PR: https://git.openjdk.java.net/jdk/pull/2615