RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific data belonging to a thread

[Aleksey Shipilev]

On 04/10/2018 02:51 PM, Per Liden wrote:
> A couple of commits were pushed, which causes conflicts with this change, so here's a rebased version:
> 
> http://cr.openjdk.java.net/~pliden/8201318/webrev.1

*) I wonder if we can make the special accessors for the composite offsets? E.g. instead of


    Address in_progress(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
                                         SATBMarkQueue::byte_offset_of_active()));
    Address queue_index(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
                                         SATBMarkQueue::byte_offset_of_index()));
    Address buffer(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
                                         SATBMarkQueue::byte_offset_of_buf()));

...do:

     Address in_progress(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_active_offset()));
     Address queue_index(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_index_offset()));
     Address buffer(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_buf_offset()));

That probably eliminates the header dependency on SATBMarkQueue/DirtyCardQueue from
compiler/assembler stubs?

*) Should these new methods accept JavaThread*? I.e. we are expecting the GC thread-local data only
for JavaThreads, like attach/detach does?

   virtual void on_thread_create(Thread* thread);
   virtual void on_thread_destroy(Thread* thread);
   virtual void on_thread_attach(JavaThread* thread);
   virtual void on_thread_detach(JavaThread* thread);

*) Wait, why do we call JVMCI members JavaThread_*?

  64     static int JavaThread_satb_mark_queue_offset;
  65     static int JavaThread_dirty_card_queue_offset;

*) I would probably add assert(UseG1GC) to G1ThreadLocalData accessor methods

Thanks,
-Aleksey