On Fri, 8 Apr 2022 02:01:50 GMT, Kim Barrett <kbarr...@openjdk.org> wrote:
> > > One open question is which MEMFLAGS to use. mtTracing doesn't seem to be > > > exactly right. Should I templatize BitSet and make JVMTI use > > > mtServiceability and JRF use mtTracing as it did before? > > > > > > Yes, I think templatizing for MEMFLAGS makes sense (concurrentHashTable.hpp > > is too). > > I haven't had time to look at the code, but I don't know about this. Slapping > a template parameter on everything isn't necessarily a good idea. We recently > (JDK-8283368) undid exactly this sort of thing in the cardset code, instead > making the MEMFLAGS value a runtime parameter provided at construction time. > This avoids a bunch of generated code duplication, additional template > syntax, and allows more implementation be put in .cpp files because it isn't > a template. I never liked MEMFLAGS as template parameter. A runtime parameter would it make easier to use a general-purpose data structure on behalf of a subsystem and account its memory to that subsystem, while still being able to pass it around as a simple pointer to other utility functions. But here Roman squirreled the template definition away into a typedef, so I think we could cleanup MEMFLAG usage in a separate RFE? (we also should move MEMFLAGS to an own header file, btw, to avoid having to pull allocation.hpp every time) ------------- PR: https://git.openjdk.java.net/jdk/pull/7964
