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

[Gerard Ziemski]

On Thu, 18 Jul 2024 05:34:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I still dislike the misuse of the enum. Among other things, this is not threadsafe, and the flag meta information should be constant after JVM initialization. It just feels wrong.
> 
> Its also unnecessary. How about this:
> 
> * number of flags is predictable and sits at ~1500, right?
> * use a stack-allocated Bitmap with 1 bit per flag. 1500 bits gives you 187 bytes. That much you can easily pay via stack allocation. If you don't have 187 bytes left on the stack, you have other problems.
> * Use Kims `Bitmap` - in fact, use `BitMapView`, the variant that works with an externally supplied memory. Let that memory be a raw array allocated on the stack, so you can be sure you don't malloc
> * Clearing is now just a memset of said raw array
> * it is threadsafe as the bitmap sits on the thread stack
> * no need to piggy-back on the enum
> * it should be even a tiny bit faster since you exchange a bit operation on spread-out words (JVMFlag is 32 bytes, so infos are spread out over 750 cachelines) with one on a tight bit array that fits completely into 3 cachelines.
> 

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). Also, is there a portable API for using stack space? I guess I am simply not that familiar with using stack space for allocations.

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.

I measured the performance:



                                  PrintFlagsInitial        Error handling

original                             25,426,861              7,389,456
JVMFlag enum                         21,882,569              2,885,973          
CHeapBitMap                          29,687,424              5,621,987



(tested on macOS x86_64)

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

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