On Fri, 8 Apr 2022 17:00:19 GMT, Thomas Stuefe <[email protected]> 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
