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

[Aleksey Shipilev]

On 04/10/2018 05:59 PM, Robbin Ehn wrote:
> On 2018-04-10 17:47, Aleksey Shipilev wrote:
>> On 04/10/2018 05:25 PM, Robbin Ehn wrote:
>>> Had quick look, what I saw looked good. (not a full review)
>>> Is there a reason for moving the gc data to 'zero offset' in Thread?
>>
>> Oh! I missed that, and I fully agree with this move. At least one reason I see, smaller offsets
>> against TLS open up opportunities for denser code-generation when e.g. GC barriers poll thread-local
>> data. Right now SATB barrier generates something like "cmpb $0x0, 0x3d8(%r15)", while it could
>> generate just "cmpb $0x0, 0x0(%r15)" now :)
> 
> Yes, but it pushes down e.g.:
> 333   volatile void* _polling_page;                 // Thread local polling page
> Which may not matter, as long as it's on the first page I suppose.

I think the major concern should be the instruction size. On x86 what matters is what category
immediate offset falls into. Some hand-crafted assembly:

   0:	48 89 42 7f          	mov    %rax,0x7f(%rdx)
   4:	48 89 82 80 00 00 00 	mov    %rax,0x80(%rdx)
   b:	80 7a 7f 00          	cmpb   $0x0,0x7f(%rdx)
   f:	80 ba 80 00 00 00 00 	cmpb   $0x0,0x80(%rdx)
  16:	80 7a 7f 41          	cmpb   $0x41,0x7f(%rdx)
  1a:	80 ba 80 00 00 00 41 	cmpb   $0x41,0x80(%rdx)
  21:	f6 42 7f 00          	testb  $0x0,0x7f(%rdx)
  25:	f6 82 80 00 00 00 00 	testb  $0x0,0x80(%rdx)
  2c:	f6 42 7f 41          	testb  $0x41,0x7f(%rdx)
  30:	f6 82 80 00 00 00 41 	testb  $0x41,0x80(%rdx)


In our case, we want to pack the most used fields under first 128 bytes. Maybe we should put polling
page at offset 0, and trim GCTLD to 96 bytes?

Thanks,
-Aleksey