RFR: 8263603: Remove leftovers of "FPE_FLT..." type signals from regular signal handling code [v2]

David Holmes dholmes at openjdk.java.net
Thu Mar 25 07:21:40 UTC 2021


On Wed, 24 Mar 2021 16:08:07 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> hello everyone,
>> 
>> Signal handling code is complex as it is, this enhancement removes, incorrect, catching & handling of `FPE_FLT` types of signals.
>> 
>> It's incorrect, because:
>> 
>> - We wouldn't want to generate/catch a floating point div by zero instructions, which by default do not cause a crash (only integer div by 0 cause crash)
>> 
>> - We can't catch them because that would require us to set **FPU** to raise such signals, which we don't do
>> 
>> - Even if we wanted to generate **FPU** signals, those only originate in **x87 FPU**, which we are not using (we use **SSE** instructions for floating point arithmetic instead) on **x86_64** architecture. Finally the API to turn it on is not even available on macOS at all (it's seems to be available on Linux, but I don't know what it actually does on **64 bit** architecture, if anything)
>> 
>> If we were to catch `FPE_FLT` signal it most likely is a bug in the OS itself, like for example [JDK-8261397](https://bugs.openjdk.java.net/browse/JDK-8261397)
>> 
>> In anticipation of such scenarios we have a generic handling of `FPE_FLT`, but we report it as OS bug that needs to be investigated.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add generic catch of FPE_FLT

Hi Gerard,

Thanks for tackling this one. 

I'm not certain we should make this a fatal condition rather than just printing a warning and throwing the exception. Perhaps use an assert.

Thanks,
David

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

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


More information about the hotspot-runtime-dev mailing list