RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific data belonging to a thread (original) (raw)

Aleksey Shipilev shade at redhat.com
Tue Apr 10 16:50:40 UTC 2018

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* pollingpage;                 // 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

More information about the hotspot-dev mailing list