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 16:28:35 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> 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.
>
> True. So I have added both. That sizeof check is for the case of:
> 
>  class ResolvedFieldEntry {
>    friend class VMStructs;
>  
> +  u4 _new_field;
>    InstanceKlass* _field_holder; // Field holder klass
> 
> Although it is a bit difficult to introduce an accidental padding inside the struct which is caught by my assertion and not by your assertion. So I can also remove the assertion of mine if you think so.

My assert also fails for your new scenario. I think we shouldn't have the hard coded numbers unless you find a case not covered by my assert. Otherwise when someone changes the class they need to update 4 hard coded numbers, which can be error prone (most people don't have 32-bit build environments).

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

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