RFR: 8366193: Add comments about ResolvedFieldEntry::copy_from()

[Andrew Dinn]

On Thu, 28 Aug 2025 13:36:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> @fandreuz @albertnetymk The problem with requiring the use of padding fields is that it is fragile. Changing a type definition might easily reintroduce the archive comparison problem and also inadvertently increase allocation sizes.
>
>> ...  that it is fragile.
> 
> Currently, an instance allocated on the stack can contain random bit and one needs to use copy-constructor/`coping_from` to clean it up seems also fragile, or even confusing that these two instances are not identical.
> 
>> Changing a type definition might easily reintroduce the archive comparison problem
> 
> You mean adding/removing fields can cause the `sizeof(ResolvedFieldEntry)` != sum of `sizeof(field)`? If so, how about having an static_assert to verify there is no padding? Since the bitwise memory content of this instance is significant, I think it's critical that we express that intention in the code -- there should not be any hole/padding inside 
> `ResolvedFieldEntry`.
> 
>> also inadvertently increase allocation sizes
> 
> Since the padding is meant to fill the holes needed for alignment, I don't think it will/should change `sizeof(ResolvedFieldEntry)`.

@albertnetymk Perhaps I was not very clear but I think you may have misunderstood what I was trying to say.

You are suggesting that we add padding bytes, shorts and/or words to structs in order to ensure that the 'payload size' (i.e. the storage needed to accommodate all the fields in declared order) is equal to the allocation size (i.e. some multiple of 4 bytes on 32 bit or 8 bytes on 64 bit). Depending on the mismatch between those two sizes we may need one or more such pad fields.

The problem I foresee is that it is very easy for a developer to make changes to the structure content or layout and either forget to adjust the padding size or adjust it incorrectly. That is what I am describing as fragile.

The consequences of getting it wrong could be 1) to recreate the archive reproduceability issue when dumping objects into CDS archives and/or 2) to end up with padding that crosses rather than runs up to a 4/8 byte boundary (which would unnecessarily increase the allocation size). In the worst case we could get both.

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

PR Comment: https://git.openjdk.org/jdk/pull/26946#issuecomment-3233988746