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

[Gerard Ziemski]

On Thu, 18 Feb 2021 18:59:51 GMT, Gerard Ziemski <gziemski 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.
>
>> > 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...
> 
> According to the **man pages** for `log()` function:
> 
> `log(x), log2(x), and log10(x) return a NaN and raise the "invalid" floating-point exception for x < 0.`
> 
> and the **man pages** for `sqrt()` function:
> 
> `sqrt(x) returns a NaN and generates a domain error for x < 0`
> 
> but what I see in our signal handler is a signal of type `FPE_FLTDIV` returned **not** `FPE_FLTINV` for `sqrt(-1.0)` and `log(-1.0)`
> 
> I can't seem to be able to get `FPE_FLTINV` at all - it's seems that it's unused natively on `macOS x86_64` so we are good I think.

> > I can't seem to be able to get `FPE_FLTINV` at all - it's seems that it's unused natively on `macOS x86_64` so we are good I think.
> 
> Ok, but I think we should fix JDK-8261966 and include
> VM_Version::is_cpu_emulated() so that we use it to gate the workaround
> at runtime. That at least minimises the exposure to the environments
> that actually need the workaround.

I added the check in this fix - I don't think we should get this issue blocked by JDK-8261966

For JDK-8261966 we can further optimize the check to cache the results, if needed, and we can have a non rushed discussion on how exactly we want the API named (ex. I would prefer to follow Apple's usage and name it is_process_translated()) and how exactly we want it to look in the hs_err log files.


cheers

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

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