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

Jan Kratochvil jkratochvil at openjdk.org
Fri Nov 7 15:11:15 UTC 2025


On Fri, 7 Nov 2025 04:48:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix 32-bit compilation error
>
> 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.

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

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


More information about the hotspot-dev mailing list