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

[Gerard Ziemski]

On Fri, 26 Jul 2024 12:42:56 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>>> > > 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.
>>> > 
>>> > 
>>> > You sure? I would have thought that if the array size is constexpr, the array would be constexpr then too.
>>> > But sure, let's define the array size separately then, as constexpr. We should get a compiler error then if its not const.
>>> 
>>> I'm sure that is the case, yes. `constexpr` is dropped if not applicable, unlike `const`. It's not initialized until after the `iteratorMarkers.clear_range(0, length);` line, so it can't possibly be `constexpr` anyway. See this Godbolt: https://godbolt.org/z/7YvbcrhqG
>>> 
>>> So I just don't understand what we're attempting to do by using constexpr here.
>> 
>> Hmm. All of your Godbolt examples look okay to me. I want the array size to be computable at compile time, no runtime-alloca-like behaviour like this: https://godbolt.org/z/xv65z4Pqe (see runtime_array()).
>
>> > > > 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.
>> > > 
>> > > 
>> > > You sure? I would have thought that if the array size is constexpr, the array would be constexpr then too.
>> > > But sure, let's define the array size separately then, as constexpr. We should get a compiler error then if its not const.
>> > 
>> > 
>> > I'm sure that is the case, yes. `constexpr` is dropped if not applicable, unlike `const`. It's not initialized until after the `iteratorMarkers.clear_range(0, length);` line, so it can't possibly be `constexpr` anyway. See this Godbolt: https://godbolt.org/z/7YvbcrhqG
>> > So I just don't understand what we're attempting to do by using constexpr here.
>> 
>> Hmm. All of your Godbolt examples look okay to me. I want the array size to be computable at compile time, no runtime-alloca-like behaviour like this: https://godbolt.org/z/xv65z4Pqe (see runtime_array()).
> 
> Aha, now I understand. Yes, the array size is constexpr so we get a statically known size for the array. For me the statement "array is constexpr" means "the contents and placement of the array is known at compile time".

@jdksjolen @tstuefe What is the consensus then? Can you please summarize your feedback?

I'm personally OK with `const` -> `constexpr` changes and would even go so far as to change all the instances of `const` in `globalDefinitions.h` 

Should I expand the `const` -> `constexpr` changes or minimize them?

Please notice that the current code seems to happily compile on all platforms in its current form.

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

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