On Fri, 8 Apr 2022 17:34:57 GMT, Roman Kennke <[email protected]> wrote:
> Yes, I get that. But the fragments and fragment-table are themselves inner
> classes that take a MEMFLAGS template. I could (perhaps) either use a
> constexpr MEMFLAGS arg and pass this through, or do at some point a switch
> like:
>
> ```
> switch (_flags) {
> case mtServiceability:
> ... new BitMapFragmentTable<mtServiceability>(); break;
> case mtServiceability:
> ... new BitMapFragmentTable<mtServiceability>(); break;
> default: ShouldNotReachHere();
> }
> ```
>
> Which seems kinda-ugly but would work (I think), and avoid making the outer
> class template-ized.
I see what you mean. This MEMFLAGS template parameter is deeply interwoven into
everything. I'd just live with the current solution. It uses established
pattern, so at least nobody is surprised.
I think the basic problem is that CHeapObj itself is a template class.
Rethinking MEMFLAGS seems worthwhile for a future RFE. As I wrote, one approach
could be to make them a property of the current thread, and switchable and
stackable via a Mark class. That way, everything allocated within a given range
of frames would count toward a given category. No need to decide on a
fine-granular basis. No need for templates. Maybe no need even to have a
MEMFLAGS argument for every allocation.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7964
