RFR: JDK-8258606: os::print_signal_handlers() should resolve the function name of the handlers [v3]

[Thomas Stuefe]

On Tue, 5 Jan 2021 17:14:43 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> src/hotspot/share/runtime/os.cpp line 896:
>> 
>>> 894:   char* p = buf;
>>> 895:   if (p == NULL) {
>>> 896:     p = (char*)::alloca(O_BUFLEN);
>> 
>> You have raised the issue of whether using `alloca(O_BUFLEN )` is a good choice elsewhere in the review, so I just wanted to quickly touch on that.
>> 
>> O_BUFLEN being 2000 bytes doesn't seem to be a big deal, still would using static array here instead be a better choice?
>> 
>> What happens if our signal handler is handling stack overflow error?
>
> Also, if we started with `malloc` and that failed, then we could try `alloca`, on the other hand `alloca` will never return an error, so we can not test and use anything else if it fails.

> You have raised the issue of whether using `alloca(O_BUFLEN )` is a good choice elsewhere in the review, so I just wanted to quickly touch on that.
> 
> O_BUFLEN being 2000 bytes doesn't seem to be a big deal, still would using static array here instead be a better choice?

A local static buffer would also live on the stack. But it would be unconditional, whereas using alloca() only uses stack space if no scratch buffer was provided.

A global static buffer would raise synchronization problems.

> 
> What happens if our signal handler is handling stack overflow error?

We'd crash again with a secondary signal. That would be handled, but the hs-err file would be compromised. Truth to be told, I have never seen a crash in an out-of-stack-space situation, its pretty rare. The only occurrences I had were when stack overflow handling itself was broken.

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

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