RFR: 8139457: Array bases are aligned at HeapWord granularity [v50]

[Roman Kennke]

On Thu, 17 Aug 2023 12:45:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> There is sth odd about `instanceOopDesc` that the header/payload reported by public API `header_size` and `base_offset_in_bytes` can be overlapping, shown picturally:
> 
> ```
> |<-header->|....     |
> |        |<-payload->|
> ```
> 
> Essentially, `header-size * HeapWordSize != base-offset-in-bytes`, blurring the boundary btw header and payload.
> 
> Possibly, it's intentional to overapproximate "header" and underapproximate "payload", because some context dependent constraints prevent `header_size` from being klass specific, i.e. having knowledge to the corresponding fields (layout). Otherwise, one should avoid declaring the existence of "klass-gap" then filling it up using some fields from the object. A klass-gap is there if and only if the first field has special alignment requirement.

With this patch, header_size() is really only a helper-method that aligns-up header_size_in_bytes() to the next word boundary, and returns that size in word-units, for use by code that need such a thing (e.g. various min/max size calculations that operate with heap-words). The source of truth regarding header-size vs payload-offset is the two methods header_size_in_bytes() and base_offset_in_bytes(). Maybe it makes sense to move out header_size() to avoid the confusion?

> > No, klass-gap really is not part of the header. For non-array objects, this gap is where the first bunch of fields go, it really is payload.
> 
> I can see where that interpretation comes from since `base_offset_in_bytes == klass_gap_offset_in_bytes` when `UseCompressedClassPointers == true` and base-offset denotes the start of payload.
> 
> It's not part of this diff -- in `C1_MacroAssembler::initialize_header`, can `movl(Address(obj, oopDesc::klass_offset_in_bytes()), t1);` use `movptr` like its 32bit counterpart?

It could, but it doesn't seem to be a good fit because a narrowKlass is not a ptr. narrowKlass are explicitly only
a 32bit int value and should be treated as such.

> Since the klass-layout-info is unavailable in this context, including this "potential" gap as part of the header is kind of overapproximation.

Yeah. If the gap is not used by instance fields or array elements, they don't actually belong to neither the header nor to the payload. It's just an alignment gap that sits in between the two. Strictly speaking they don't even need to be cleared (and I believe C2 would not clear it in any case) because it's not accessed, ever. But we don't have that info for instances, so we clear it anyway. *If* the gap is used (and that is common), it's clearly payload.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1297619380