> On Apr 9, 2022, at 2:44 AM, Thomas Stuefe <stu...@openjdk.java.net> wrote: > > On Fri, 8 Apr 2022 17:34:57 GMT, Roman Kennke <rken...@openjdk.org> 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.
While working on something else I ran into a similar problem and found a different approach that seemed to work well. I’m planning to explore it in the context of CHeapObj, but haven’t gotten around to it yet. I should file an RFE in case someone else is interested.