RFR: 8301403: Eliminate memory allocations during signal handling

[Thomas Stuefe]

On Wed, 17 Jul 2024 12:00:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> 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?

I think the gist of my concern would be:
- for hs-err file use, it may not matter
- for non-hs-err file usage, when we print all flags, it may not be enough: We have 2.25 mio string comparison operations (1500 flags ^ 2), and the enum trick halves that number, which still leaves us with 1.125 mio string comparisons.

All in all, I welcome this patch and the fact that you look into reducing malloc usage, though. The next spot to look at with very raised eyebrows would be the elf decoder used to print stack frames ;)

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

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