RFR: 8344734: Rename memoryFileTracker to nativeMemoryFileTracker [v5]

[Gerard Ziemski]

On Mon, 28 Apr 2025 11:37:59 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> Checkin in extensive renaming changes, from my personal experience, can be a pain. I would prefer to split those if we can.
>> 
>> If you want to have a discussion about the names, we can have it right now, no problem. That is an orthogonal issue in my opinion, that we can settle without worrying about how we mechanically do it.
>> 
>> @jdksjolen  Do you have any names we should start considering?
>
>> Checkin in extensive renaming changes, from my personal experience, can be a pain. I would prefer to split those if we can.
>> 
>> If you want to have a discussion about the names, we can have it right now, no problem. That is an orthogonal issue in my opinion, that we can settle without worrying about how we mechanically do it.
>> 
>> @jdksjolen Do you have any names we should start considering?
> 
> Sure,
> 
> I don't see any advantage in adding a 'Native' prefix to this class. If we are concerned with being able to recognise that something is from NMT then we should add an `nmt` (or `NMT`, or `Nmt`) namespace and place our datastructures into that namespace. This change can be done incrementally.
> 
> Additionally, if the plan for this type of work is to have follow ups, then I want all of the JBS issues to be created at once and assigned to the person who is going to implement it. Potentially, as a main issue and subtasks (see nullptr conversion for how that was done as inspiration).
> 
> Cheers,
> Johan

@jdksjolen What should Anton do about this fix then? Abandon it or check it in?

It's probably his early, learn the process of checking in fix, type of issue.

Personally, I'm OK with Anton checking this one in, to let the learning experience here finish, but what do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/24579#issuecomment-2839541812