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

[Albert Mingkun Yang]

On Thu, 28 Aug 2025 12:16:34 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> ...  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)`.

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

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