On Fri, 8 Apr 2022 14:17:06 GMT, Roman Kennke <rken...@openjdk.org> wrote:
> > Here's an idea. Add an mtflag called mtBitMap and use that. There's plenty > > of bits in mt flags. > > Naa, I don't think this is justified. It isn't used as widely or frequently > to warrant its own flag. Plus, it would muddy the water, since what we actually want is the memory accounted toward the subsystem on behalf of which we create the data structure. mtBitMap would be a bit like "mtArray" for GrowableArray. Note that there was the idea, and an associated JBS issue (https://bugs.openjdk.java.net/browse/JDK-8281819) of making NMT categories groupable in a one- or multi-layered hierarchy. That way, one could account to "mtGC" -> "mtBitSet", for instance. For now, I opt to either live with what we have with the typedef'ed BitSet, and leave MEMFLAG cleanups to a later RFE. Alternatively, make the MEMFLAG a runtime parameter of the bitset, use that for the heap allocated fragments, but use "mtInternal" for the actual class. I mean, those are just a few bytes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964
