PtrQueue provides static accessor functions providing the offsets to and sizes of data members, for use by compilers in the generation of the various G1 store barriers. Callers are actually interested in the member offsets in the derived classes (SATBMarkQueue and DirtyCardQueue), but access them via PtrQueue. PtrQueue should be viewed as an implementation detail of the derived classes, and this direct access via PtrQueue is an abstraction violation that makes it unnecessarily difficult to refactor these classes. (As an example, only SATBMarkQueue really uses the _active member, and it would be better placed in that class rather than in PtrQueue with DirtyCardQueue always assigning a true value and paying the overhead for it.)

It would be better if clients were explicit about which derived class member they were interested in, with the present PtrQueue providing protected helpers for the implementations provided by the derived classes.

In addition, JVMCI presently uses VMStruct field offset access to get the same information, rather than using the public API provided for compiler use and used by all compilers/interpreters. It would be better if JVMCI used the same mechanism as everyone else.