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