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

[David Holmes]

Hi Gerard,

On 19/02/2021 5:02 am, Gerard Ziemski wrote:
> On Thu, 18 Feb 2021 16:28:38 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:
> 
>>> 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)`

Thanks for the further investigation here.

Possibly more bugs in FP handling. :(

Though I'm unclear how to actually trigger SIGFPE in these cases - don't 
we have to enable traps at the CPU level via the FPU control word? I 
placed this in os::init_2() on Linux:

double d = ::sqrt(-1.0);
printf("%f\n", d);

and it just prints "-nan" with no signal generated.

> 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.

Thanks,
David



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