RFR: 8301403: Eliminate memory allocations in JVMFlag::printFlags during signal handling

[Gerard Ziemski]

On Wed, 17 Jul 2024 13:16:50 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 ;)

I checked the performance when we print all the flags. With qsort it takes 21,882,569 ns and with my fix it takes 25,426,861 ns, which is a slow down of x1.16 times.

Personally I would keep the code simpler and have just one code path. What do you think?

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

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