RFR: 8337563: NMT: rename MEMFLAGS to MemFlag

Gerard Ziemski gziemski at openjdk.org
Tue Aug 27 21:16:31 UTC 2024


On Thu, 15 Aug 2024 06:31:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> I agree with @tstuefe here. MemFlag and MemType sound far too general when this is NMT specific.
>> 
>> Yes, it is not very specific, but it also not hard to learn and then know what this type is all about.
>> 
>>> My preference to keep the "flags" part of the type was to avoid needing to rename many parameters. The usage of MEMFLAGS flags is quite extensive. I would not want to see a partial approach here where we end up with a non-flag type name but a flag variable name.
>> 
>> I think we should rename all the 'flags' variables in the same change.
>> 
>>> NMTTypeFlag would I hope satisfy Thomas's requirement and avoid the need to do variable renames.
>> 
>> * To me, that's really not an appealing name for a type that is going to be used by all parts of the HotSpot code base. I much more prefer a shorter name that is easy on the eyes, then a longer and more specific name that is an eyesore.
>> 
>> * And even as a longer name, it doesn't tell what it is going to be used for. What is a Native Memory Tracker Type Flag?
>> 
>> * I don't want us to select a bad name so that we don't have to change the variable names.
>> 
>> * Whatever we choose we also need to consider the mt prefix of things like mtGC, mtClass, etc.
>> 
>> With all that said, I hope it is clear that we various reviewers have different opinions around this and that we don't integrate this before we have some kind of consensus about the way forward with this.
>
>> What is a Native Memory Tracker Type Flag?
> 
> It is a flag telling us the type of native memory being tracked.
> 
>> Whatever we choose we also need to consider the mt prefix of things like mtGC, mtClass, etc.
> 
> And what does that stand for: memory type? memory tracker? Arguably they should have been nmtGC etc.
> 
>> I think we should rename all the 'flags' variables in the same change.
> 
> Okay. That's a big change but I'd prefer it to any half-way measures.

@dholmes-ora @tstuefe @stefank @kimbarrett @afshin-zafari @jdksjolen 

hi all,

I would like to see if we can give this another go, now that we got some time to sleep on it.

How about this - I created a table with some name candidates, so everyone can see where everyone else is. We all can choose 3 candidates that we can rank 1, 2 and 3. At the end we tabulate the answer and the one with highest score wins?

| developer | MemType | MemTypeFlag | NMTCat | NMTGroup | NMT_MemType | NMT::MemType |
| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| gerard | 1 | 0 | 0 | 0 | 2 | 3 |
| David  | ? | ? | ? | ? | ? | ? |
| Thomas | ? | ? | ? | ? | ? | ? |
| Johan  | ? | ? | ? | ? | ? | ? |
| Afshin | ? | ? | ? | ? | ? | ? |
| Stefan | ? | ? | ? | ? | ? | ? |
| Kim    | ? | ? | ? | ? | ? | ? |

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

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2313584428


More information about the shenandoah-dev mailing list