RFR: 8365661: oops/resolvedMethodEntry.hpp could use default copy constructor [v3]

[Ioi Lam]

On Mon, 25 Aug 2025 17:40:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The problem with the default copy constructor is it might copy random values from the padding bytes:
> 
> ```
>   InstanceKlass* _field_holder; // Field holder klass
>   int _field_offset; // Field offset in bytes
>   u2 _field_index; // Index into field information in holder InstanceKlass
>   u2 _cpool_index; // Constant pool index
>   u1 _tos_state; // TOS state
>   u1 _flags; // Flags: [0000|00|is_final|is_volatile]
>   u1 _get_code, _put_code; // Get and Put bytecodes of the field
>   // 1 padding byte on 32-bit
>   // 5 padding bytes on 64-bit
> ```
> 
> This will cause failures in test/hotspot/jtreg/runtime/cds/DeterministicDump.java on certain platforms.
> 
> If you want to use the copy constructor, you need to add the padding bytes fields by hand and explicitly set them to zero in ResolvedFieldEntry::remove_unshareable_info().
> 
> I am not sure if structure padding is compiler-specific or not, so it might be difficult to write portable code.

I am sorry, the problem is not with `ResolvedFieldEntry::remove_unshareable_info()`, but rather the `ResolvedFieldEntries` that are *not* cleaned by this function. 

https://github.com/openjdk/jdk/blob/0f7c0e956e278458e3d875bbda174e3b9e143135/src/hotspot/share/oops/cpCache.cpp#L433-L438


    if (resolved && AOTConstantPoolResolver::is_resolution_deterministic(src_cp, cp_index)) {
      rfi->mark_and_relocate();  /// <--- HERE
      archived = true;
    } else {
      rfi->remove_unshareable_info();
    }


Note that `rfi` is allocated from within the metaspace, so originally it contains all zeros. However, sometimes we read a `ResolvedFieldEntry` from a GrowableArray and store it inside `*rfi`. If we use the default copy constructor, the copy inside the GrowableArray may have junk in its gaps, and the junk will leak into `*rfi`.

If I remember correctly, this problems is most prominent on Windows. It's probably because Windows likes to use aligned copies to move stack variables into the GrowableArray, taking whatever junk from the stack.

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

PR Comment: https://git.openjdk.org/jdk/pull/26818#issuecomment-3222570091