RFR: 8254824: SignalHandlerMark have no purpose

[Robbin Ehn]

On Fri, 16 Oct 2020 07:08:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > 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.
> 
> I see your point now, I agree with you that it could be useful information. But its very easy to re-introduce if we
> want. We don't even need a RAII object, we could just increase the signal nesting level in javaSignalHandler() directly.

If you execute any code which takes a Mutex you risk deadlocking, since they are not recursive and pthread_mutex is not
signal safe. (if they were you risk that the data they are protecting are inconsistent when reading it from signal
handler any ways) Any code path not carefully review should be considered unsafe to potentially re-enter from signal
handler. We also on purpose call code which is not signal safe, e.g. vfprintf is not signal safe, thus any code that
can log is not safe AFAICT. So just one check in one specific case is not that useful and since we do call unsafe code
intentionally the rules are very fuzzy.

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

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