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

Reply via email to