RFR: 8283710: JVMTI: Use BitSet for object marking [v6]
Roman Kennke
rkennke at openjdk.java.net
Fri Apr 8 17:37:03 UTC 2022
On Fri, 8 Apr 2022 17:00:19 GMT, Thomas Stuefe <stuefe at 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
More information about the serviceability-dev
mailing list