RFR: 8357579: Compilation error: first argument in call to 'memset' is a pointer to non-trivially copyable type [v7]

[Ioi Lam]

On Fri, 7 Nov 2025 15:08:07 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> src/hotspot/share/oops/resolvedMethodEntry.cpp line 43:
>> 
>>> 41: STATIC_ASSERT(sizeof(ResolvedMethodEntry) == 16);
>>> 42: # endif
>>> 43: #endif
>> 
>> I think this can be cleaned up as:
>> 
>> 
>> #ifdef _LP64
>> STATIC_ASSERT(sizeof(ResolvedMethodEntry) == DEBUG_ONLY(32) NOT_DEBUG(24));
>> #else
>> STATIC_ASSERT(sizeof(ResolvedMethodEntry) == DEBUG_ONLY(20) NOT_DEBUG(16));
>> #endif
>> 
>> 
>> But I think this will be better without the need to hard code numbers:
>> 
>> 
>> // There should be no more padding at the end of ResolvedMethodEntry
>> class ResolvedMethodEntryWithExtra : public ResolvedMethodEntry {
>>   u1 _extra_field;
>> };
>> STATIC_ASSERT(sizeof(ResolvedMethodEntryWithExtra) > sizeof(ResolvedMethodEntry));
>> 
>> 
>> I tested by changing `u4 _padding2` to `u4 _padding2` in `ResolvedMethodEntry` and the static assert fails.
>
> This STATIC_ASSERT does work for the trailing padding but not for potential padding introduced inside the struct. That sizeof(x)==number of mine is also not foolproof, but IMHO it is slightly safer.

I don't think either approach can detect internal padding. E.g., I changed this:


# ifdef _LP64
- u2 _padding1;
+ u1 _padding1;
  u4 _padding2;


Neither static assert failed.

But if I changed this:


# ifdef _LP64
  u2 _padding1;
- u4 _padding2;
+ u2 _padding2;


My assert fails but yours doesn't. So hard coding a number cannot detect trailing paddings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26098#discussion_r2504302756