RFR: 8297718: Make NMT free:ing protocol more granular [v2]

[Johan Sjölen]

On Thu, 8 Dec 2022 07:40:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > I quickly find this more complex than another line of plain code at the call site would be.
> > 
> > 
> > My concern with the latter is the breaking of encapsulation and pollution of the callsite with details it has no business knowing about. To some extent some knowledge has to leak to the callsite to know either which API to call, or which flag parameters to pass, but that should be minimised and as generic as possible.
> 
> Okay, I see your point (and @gerard-ziemski ). But having to know when to pass false, and what false does, also breaks encapsulation.
> 
> A good encapsulation would be breaking MemTracker::record_free into three clearly named APIs then, without demanding knowledge about what they do:
> 
> ```
> opaque_thingy MemTracker::prepare_free(void* payload);
> void MemTracker::commit_free(opaque_thingy);
> void MemTracker::rollback_free(opaque_thingy);
> ```

A general comment on this thread of reasoning: The original `::record_free()` required a comment in `os::free` that explained exactly what it does, anyway. That's not an abstraction. Functions such as `os::free()` and `os::realloc()` should be written by devs that are knowledgeable in NMT, so having a granular API for these parts isn't bad. If this was a "user level" usage, then I'd be more prone to hiding these details.

I'm generally against flags to alter behavior, for the reasons Thomas has already expressed.

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

PR: https://git.openjdk.org/jdk/pull/11390