RFR: 8254824: SignalHandlerMark have no purpose

[Coleen Phillimore]

On Thu, 15 Oct 2020 17:32:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Changes requested by dholmes (Reviewer).
>
>> As much as I like seeing old code removed, wouldn't this be something that would be useful? Should Mutex::lock with
>> safepoint check for instance check for this?
> 
> Maybe. But as it is, beside being unused it is pretty inconsistent: only the main signal hndler uses this, not the
> SR_handler nor the secondary error handler. So, Thread::_num_nested_signal would only ever be >1 if a second signal
> happened right inside the signal handling but before fatal error handling kicks in, which as its first step installs
> the secondary error handler.  BTW one thing I wondered about is that all the JVM_handle_xxx_signal() functions return
> an int; but we return anything out of {true, false, 0, 1.} And the return value is then ignored at the caller. For
> example, the "abort_if_unrecognized" option does not seem to do anything - can probably be removed.

So the code I was worried about is the code between JVM_handle_x_signal and calling report_and_die.  There's a lot of
duplicated code in JVM_handle_x_signal.  I moved some of it but if we move more of it far away, it would be nice to
know we aren't calling Thread::current() or some Mutex inside of the signal handler.  That said, I'm ok with its
deletion.

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

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