On Mon, 2 Sep 2024 04:03:28 GMT, David Holmes <dhol...@openjdk.org> wrote:
> FWIW as I recall the suggestion to include NMT in the name in some form was > to make it clear that these kinds of parameter, which appear all over the > place, are needed because of NMT and are not inherently part of whatever API > they appear in. Whether that happens via a namespace, a nested enum, or a > simple prefix, I don't really care except to say that anything that can then > result in dropping the NMT in the source code (e.g. via a using directive) > completely defeats the purpose of having it in the first place. So if there > is no good answer here than I guess we just drop NMT from the name. Kim and Stefan said that any consideration of using namespace would require additional discussion. And almost everyone dislikes adding the `NMT_` prefix. I feel like we achieved (imperfect) agreement that allows us to proceed with a cleanup using `MemTag` as the new type name to replace `MEMFLAGS`, which I hope everyone agrees is an improvement. I am almost done with that name change and I see it as a significant improvement worthwhile of this effort, with anything else that can be handled in followups, however, if you feel strongly that we should discuss the full topic right now, before proceeding, please let it be known here. Personally I just wanted to cleanup `MEMFLAGS` and related `flag(s)` names that we used in very inconsistent matter. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2327019788
