RFR: 8287089: G1: Change const <type>* name to <type>* const name in arguments

[Thomas Schatzl]

On Sat, 21 May 2022 11:15:06 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>>> Also note that in a (non-definitional) declaration, a top-level CV qualifier
>> is ignored. So a parameter of type T* const is the same as a parameter of
>> type T*. The const only has impact in a definition, when it declares the
>> variable (as opposed to its value) as constant.
>> 
>> That may well be (and actually I tried it out and you are right - that has been new to me), I would prefer to keep the declaration and the definition exactly the same, even if superfluous.
>> 
>> E.g. we could write
>> 
>>   class X {
>>     void square(char* x) const;
>>   };
>>   void X::square(char* const x) const {
>>     ...
>>   }
>> 
>> and this compiles. I would strongly prefer to not do this and keep declaration and definition exactly the same.
>
>>>    I don't know what "pb" is in that signature, but the const qualifier for it isn't useful.
>>Similar to many other parameters here, pb is going to be (random) pointer into the heap region where the its value should not change in the method.
> 
> It would not hurt to have `const T* const pb` for that case either, because the method isn't supposed to modify the referenced contents either - however the main point of the author in that case (and what I'm trying to convey here, in at least many of the other cases as well) that the pointer value itself should be constant, and it would be nice to have that reflected.
> 
> E.g. the author saw:
> 
> 
> void method(const oop b);
> 
> and then added, because it was needed:
> 
> void method(const HeapWord* b);
> 
> as a variant - which also compiles and works, but it is not as intended.
> 
> Note that maybe I'm wrong here, and the original author intended `const T* const something` for all these cases (it's hard to find that out after long time passed); but I'd argue there is very little const`ing to that degree in Hotspot code. There is of course also room for improvement here.

Okay, I agree about `block_size` now after some more thinking. I'll look over the various suggestions from me a bit.

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

PR: https://git.openjdk.java.net/jdk/pull/8815