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

Aleksey Shipilev shade at redhat.com
Wed Apr 11 16:03:14 UTC 2018

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::gcdata() 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

More information about the hotspot-dev mailing list