RFR: 8301403: Eliminate memory allocations in JVMFlag::printFlags during signal handling [v10]
Johan Sjölen
jsjolen at openjdk.org
Fri Jul 26 06:59:37 UTC 2024
On Fri, 26 Jul 2024 00:01:47 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...
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>
> follow the chain for constexpr
I like how `constexpr` spread like butter on toast throughout the codebase. What I don't get is what `constexpr` gives us here. Line 705 isn't declared as `constexpr`, so this is just evaluated at runtime. I don't mind "constexpr:ing all the things", but I think the intention was something other than that.
-------------
PR Review: https://git.openjdk.org/jdk/pull/20202#pullrequestreview-2201075895
More information about the hotspot-runtime-dev
mailing list