On Fri, 8 Apr 2022 17:00:19 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
> > > We must call new on it somewhere. I am not opposed to making this an > > > mtFlags template then. This is a small point in this improvement. > > > > > > Yes, at some point we need to allocate the fragments and fragments table. > > We could _perhaps_ work around it by passing MEMFLAGS as constexpr, but I > > don't think this would change generated code much. > > (all bikeshedding since we all agree the current version is fine, no?) > > No, sorry, I meant make BitSet a normal class. Not derived from CHeapObj, > since it gets not newed, only used via composition or on a stack. And give it > a runtime parm to set the MEMFLAG. > > So: > > ``` > class BitSet { > const MEMFLAGS _flags; > public: > BitSet(MEMFLAGS f = mtInternal) : _flags(f) {...} > }; > ``` > > and use those flags for the c-heap allocation of the fragments. 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964