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

Johan Sjölen jsjolen at openjdk.org
Fri Jul 26 12:45:33 UTC 2024


On Fri, 26 Jul 2024 11:45:37 GMT, Thomas Stuefe <stuefe 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()).

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".

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

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


More information about the hotspot-runtime-dev mailing list