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

[Thomas Stuefe]

On Fri, 19 Jul 2024 18:19:11 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> I would prefer not to use a solution using stack (I keep thinking of all the platforms that Java may run on, and some of them might not have as much stack room as modern desktop machines). 

We are talking about 187 bytes. That is 20ish stack words. If your stack pointer is that close to the guard page, you won't be able to do much anyway. You may even crash out in strcmp, since that involves at least one, probably multiple new invocation frames.

> How about we preallocate CHeapBitMap with the size of all the flags (~1,500). That can't take much more than a few hundred bytes.

Not thread-safe, nor re-entrant-safe. I don't think it matters much, but why risk it? 

> I measured the performance:

Note that your solution has an unnecessary double indirection, since you allocate the CHeapBitmap in the C heap and its backing memory is also allocated on the C heap. Two pointer hops per bitmap at().

---

If you are set on your enum idea, that is fine. I just worry that such coding will bite us in the future if we ever want to refactor flag handling. But I don't want to drag this PR out if you want to be done with it.

For the future, the coolest would be to have compile-time sorting. E.g. some small script that runs during make and that generates a sorted index list which then could be baked into the binary. E.g. a constexpr short[] array (since highest index < 64k). No setup costs, no sorting at runtime, paid for with a minimal text segment size increase.

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

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