JDK-8263386 : Do we need to restrict workaround for JDK-8261397 even further?
  • Type: Task
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 17
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2021-03-10
  • Updated: 2021-03-16
  • Resolved: 2021-03-15
Related Reports
Relates :  
JDK-8263603 - Remove leftovers of "FPE_FLT..." type signals from regular signal handling code
Relates :  
JDK-8017106 - -XX:+UseLargePages is not rejected on MacOSX - causing crashes at startup
Relates :  
JDK-8261397 - try catch Method failing to work when dividing an integer by 0
Description
For JDK-8261397 we check if we are running in emulation mode (i.e. Rosetta) on David Holme's request when he raised the original question of how safe is the workaround.

Mikael Vidsteadt raised the issue again, so need a definitive answer on what are the risk of the workaround of mapping "FPE_FLT..." (explicitly here the "FPE_FLTINV") to "FPE_INTDIV"

Are the "FPE_FLT.." used at all?

My initial investigation, documented in https://github.com/openjdk/jdk/pull/2615 revealed no, but need to investigate further.

Apple has fixed their bug, so conceivably we can only activate the workaround for those macOS version that have the bug.
Comments
There is also JI-9068904 which shows: siginfo: si_signo: 8 (SIGFPE), si_code: 5 (FPE_FLTINV), si_addr: 0x0000000112e7dc08 where "si_code=5" really is FPE_FLTINV but that turns out to be an actual duplicate of JDK-8261397
16-03-2021
I've done some research and it looks like the "FPE_FLT..." subset of the signal types originates from x87 (i.e. float point coprocessor), which is not used by default on x86_64 (current gcc will not compile to it by default), so as far as hotspot VM is concerned they should never occur. Of course, as we saw in JDK-8261397, a bug in OS can make other signals masquerade as such. Instead of x87 FPU the x86_64 architecture uses SSE, SSE2, SSE3 instructions and those do not generate "FPE_FLT..." On Linux OS (32bit only?) one can enable "FPE_FLT..." signals with feenableexcept() API, but that API is not even available on macOS platforms at all. And it's very questionable whether a user would even really want such signals. One more note: the signals generated as "FPE_INT..." signals, which are described as a "floating point" signals, are integer math signals and they originate in the CPU not FPU.
16-03-2021
JDK-8017106 shows "FPE_FLTINV", but I analyzed it and to me it looks like it really was "FPE_INTDIV". It looks eerily similar to the Apple's mislabelling FPE_INT as FPE_FL just like recently in JDK-8261397
10-03-2021