JDK-8263603 : Remove leftovers of "FPE_FLT..." type signals from regular signal handling code
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 17
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • CPU: x86_64,sparc_64,aarch64
  • Submitted: 2021-03-15
  • Updated: 2024-01-11
  • Resolved: 2024-01-11
Related Reports
Relates :  
JDK-8263997 - Remove old workaround for SIGFPE & FPE_INTDIV
Relates :  
JDK-8263386 - Do we need to restrict workaround for JDK-8261397 even further?
Relates :  
JDK-8017106 - -XX:+UseLargePages is not rejected on MacOSX - causing crashes at startup
Description
After investigating JDK-8263386 it appears that we are not using "FPE_FLT..." signals, and on modern platforms 64bit we can't even use them if we wanted to, because those signals originate in x87 FPU, which are not used in favor of SSE instructions.

We should remove references to "FPE_FLT..." in our code to make clear that the code is not using or expecting them in normal signal handling situation.

We should, however, have a catch case looking for such signals and print a warning about unexpected signal type to catch possible OS bugs, such as JDK-8261397
Comments
Runtime Triage: This is not on our current list of priorities. We will consider this feature if we receive additional customer requirements.
11-01-2024
I wonder why we have this code: #ifdef __APPLE__ } else if (sig == SIGFPE && info->si_code == FPE_NOOP) { int op = pc[0]; // Skip REX if ((pc[0] & 0xf0) == 0x40) { op = pc[1]; } else { op = pc[0]; } // Check for IDIV if (op == 0xF7) { stub = SharedRuntime::continuation_for_implicit_exception(thread, pc, SharedRuntime:: IMPLICIT_DIVIDE_BY_ZERO); } else { // TODO: handle more cases if we are using other x86 instructions // that can generate SIGFPE signal. tty->print_cr("unknown opcode 0x%X with SIGFPE.", op); fatal("please update this code."); } #endif /* __APPLE__ */
19-03-2021