RFR: 8301403: Eliminate memory allocations during signal handling

[Thomas Stuefe]

On Tue, 16 Jul 2024 20:44:00 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Allocating memory while handling an error should be avoided, however `JVMFlag::printFlags()` is used by crash log and it allocates memory to print flags sorted (using qsort).
> 
> We avoid memory allocation by using a simple in place algorithm that uses JVMFlag 1 bit of unused data from its private `Flags` enum data member. It is O(n^2) algorithm, compared to O(n*log(n)) for qsort, however, it's called while handling an error log, so the speed here is not paramount. Also, I measured the real impact on a simple test case and I actually observed performance improvement of about x2.5 faster (2,885,973ns in place ordered printing vs 7,389,456ns for qsort). This is because we ended up having to qsort all flags when only a fraction of them actually end up being printed.
> 
> Running MACH5 tests...

When called from hs-err printer, the old code sorts all flags instead of pre-filtering only those it wants to print, which is unnecessary and makes a huge difference. We have ~1500 flags in total, but usually only print 20-30.

The enum flag avoids about half the strcmp calls, but with 20-30 printed strings, does this really matter here? (I am mostly concerned about code complexity).

OTOH for those cases (non-hs-err) where we do print the full flag range, e.g. PrintFlagsFinal: How big of a speed loss is the now quadratic algorithm?

Maybe we need two variants. One for hs-err (print_safe, no memory allocated) and one for normal ops (print_fast, uses qsort)

Note that for qsort, using a *pointer* array has always been wasteful. We have 1500 entries, sorting them could be done with an index array consisting of shorts. Only uses a quarter of the memory.

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

PR Comment: https://git.openjdk.org/jdk/pull/20202#issuecomment-2233151574
PR Comment: https://git.openjdk.org/jdk/pull/20202#issuecomment-2233154891