Currently the two PtrQueue instances for G1 are located in G1's thread local data.

There are a few issues here:
- this means that the members of PtrQueue that the compiled code needs are all over the place and interspersed with other data not required by the compiled code. Another example are the C++ class headers (VMTs) which take away 16 bytes.

- at the moment the last index used by the compiler is already 120 (DirtyCardQueue::_buf) - which for x86 is actually the last index that can be used with short offsets from TLS. So adding anything else will cause suboptimal code generation/density.

- using too large sizes just wastes precious (cache) space

One option could be to move the data that is used by compiled code into an extra data structure (e.g. PtrQueueData, but certainly there are better names) and embed that one.

Minimally these are _buf and _index (i.e. with JDK-8256279 implemented). Only having these however has the problem that actual enqueuing does not know where to put full buffers. This could either be fixed by adding _qset there, or different entry points for the two necessary PtrQueueSets.

There are some setup issues that need to be looked at as now PtrQueue and PtrQueueData reference each other.