While investigating JDK-8263603 I noticed this code:

      if (sig == SIGFPE /* && info->si_code == FPE_INTDIV */) {
        // HACK: si_code does not work on bsd 2.2.12-20!!!
        int op = pc[0];
        if (op == 0xDB) {
          // FIST
          // TODO: The encoding of D2I in x86_32.ad can cause an exception
          // prior to the fist instruction if there was an invalid operation
          // pending. We want to dismiss that exception. From the win_32
          // side it also seems that if it really was the fist causing
          // the exception that we do the d2i by hand with different
          // rounding. Seems kind of weird.
          // NOTE: that we take the exception at the NEXT floating point instruction.
          assert(pc[0] == 0xDB, "not a FIST opcode");
          assert(pc[1] == 0x14, "not a FIST opcode");
          assert(pc[2] == 0x24, "not a FIST opcode");
          return true;
        } else if (op == 0xF7) {
          // IDIV
          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 on bsd.
          tty->print_cr("unknown opcode 0x%X with SIGFPE.", op);
          fatal("please update this code.");
        }
The Linux version has this comment:

// HACK: si_code does not work on linux 2.2.12-20!!!

Linux 2.2.12-20 according to https://en.wikipedia.org/wiki/Linux_kernel_version_history is from 20 years ago.

Dan thinks this code was just an unneeded code introduced from Linux-->BSD port task, so we should remove it.

Even on Linux, however, we surely don't need a workaround for a 20 year old Linux kernel - si_code does work correctly nowadays.

We should remove this dead code, that only adds complexity to the already complex POSIX signal handling.