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

[David Holmes]

Hi Gerard,

On 27/03/2021 1:01 am, Gerard Ziemski wrote:
>>> On Thu, 25 Mar 2021 07:19:17 GMT, David Holmes <dholmes at openjdk.org> wrote:
>>>> 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
>>>
>>>
>>> Thank you David for the review.
>>> I figured that if we were to get such unexpected signal we would be in unknown territory, but I can change it to assert instead.
>>
>> Note that I also suggested that we throw the exception. I don't think we
>> can just do nothing here as it implies we'd return potential junk to a
>> FP computation. Though in that case is there actually any point in
>> making any changes to this code?
>>
>> While we no longer use the x87 co-processor in hotspot code, I'm
>> concerned there may be legacy third-party libraries that may still use
>> it via their own native code, and so potentially enable and trigger
>> these floating-point signals.
> 
> I'm not sure we were ever enabling x87 signals. I seriously doubt we ever wanted to do that (on purpose) or that we had it in fact ever enabled.

But this isn't just about x87 signals. The use of SSE can also generate 
hardware exceptions that can manifest as signals at the OS level.

> 3rd parties could/should add their own signal exception handling for x87 FPU if they want it. Those are very domain specific, and if they wanted them they would certainly not want us handling them.

The fact we turn a SIGFPE FPE_FLTDIV into a Java ArithmeticException may 
be exactly what they want. They may have discovered they don't need to 
install their own handlers precisely because the VM handles things how 
they expect. Though this begs the question as to why they would enable 
signals in the first place ... though with signal chaining things might 
again work as hoped.

> I think this is a very dead code, that unnecessarily complicates our signal handling with zero benefit and I personally would love to see it go away, especially now that we have an understanding of what FPE_FLT signals are. There is enough signal handling code that we do need to support as it is.
> 
> Is that a good enough argument, or are you still unconvinced and you don't want to see it fixed?

Sorry, if this was x87 only then I could accept the dead code argument, 
but as it seems applicable to SSE as well then ... it just isn't clear 
to me we can get rid of this code without impacting some end users. And 
the change to the code hardly makes a difference to 
understandability/readability. In fact if macOS did not have the 
FPE_FLTINV bug, we would still need the FPE_FLTDIV check that you are 
proposing to remove!

Cheers,
David
-----

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