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