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

[Aleksey Shipilev]

On 04/11/2018 05:56 PM, Per Liden wrote:
>>     // The current size of GCTLD is kept under 128 bytes to let compilers encode
>>     // accesses to all GCTLD members with short offsets from the Thread. This is not
>>     // a hard requirement: we can have fields past 128+ bytes, but low-offset fields would
>>     // be more efficient to access. Therefore, consider putting more frequently used
>>     // fields first in GCTLD, in case GCTLD size is extended in future and/or moved
>>     // within the Thread.
> 
> I have the feeling we mean the same thing, but maybe we're coming at this slightly from different
> points of view. To me, talking about the size of GCTLD risks misleading the reader. We're not really
> keeping the size under 128 bytes today to because of instruction encoding. We keep it at 112 because
> that's enough to cover our current space needs. However, I think the last part of your proposal
> captures the main point, i.e. placing frequently accessed fields first is generally a good idea to
> optimize instruction encoding. So, to keep things simple, how about this:
> 
> ...
> // Use Thread::gc_data<T>() to access the data, where T is the
> // GC-specific type describing the structure of the data. GCs
> // should consider placing frequently accessed fields first in
> // T, so that field offsets relative to Thread are small, which
> // often allows for a more compact instruction encoding.
> ...
> 
> I'm intentionally not stating a specific offset limit here, since that's is architecture dependent.
> 
> Reasonable?

Yup, thanks!

-Aleksey