RFR: 8376822: UseCompactObjectHeaders: fill Klass alignment gaps in AOT cache [v3]

[Ioi Lam]

On Thu, 26 Feb 2026 16:58:45 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - @lmesnik comment: added test case
>>  - @johan-sjolen comments
>
> src/hotspot/share/cds/archiveBuilder.cpp line 641:
> 
>> 639: void ArchiveBuilder::make_shallow_copy(DumpRegion *dump_region, SourceObjInfo* src_info) {
>> 640:   address src = src_info->source_addr();
>> 641:   int bytes = src_info->size_in_bytes();
> 
> Earlier code had special handling for `SymbolType`:
> ```    
>     // Symbols may be allocated by using AllocateHeap, so their sizes
>     // may be less than size_in_bytes() indicates.
>     bytes = ((Symbol*)src)->byte_size();
> 
> Is that not needed now? I guess it shouldn't matter because `src_info->size_in_bytes()` for SymbolType returns bytes aligned to HeapWordSize which is same as `SharedSpaceObjectAlignment`. So the earlier code was passing the actual size of Symbol in bytes and `DumpRegion::allocate` would align it to `SharedSpaceObjectAlignment` but now the `bytes` should already by aligned to `HeapWordSize` or `SharedSpaceObjectAlignment`. It would probably result in memory wastage if ever `HeapWordSize` is more `SharedSpaceObjectAlignment`. Right?

The main reason I removed this is because the comment is wrong, as `Symbol::size_in_bytes()` doesn't change whether the Symbol is allocated with heap or not.

Also, as you pointed out, since we align all allocations with `SharedSpaceObjectAlignment`, we don't need special handling for Symbols. It's unlikely that we will change `SharedSpaceObjectAlignment`, as most objects have 64 bit fields so we must align the beginning of these objects at 64-bit boundaries. Otherwise we will break some platforms (e.g. arm requires 64-bit alignment for double-word load/store) or compilers that have similar assumptions.

In the future, we can try to allocate Symbols on 4-byte alignments -- we have 46224 Symbols in the default CDS archive.  8 byte alignments waste 3.5 bytes per symbol on average. Changing to 4 byte alignment will gain 2 bytes per symbol, or about 100K for the default archive of about 15MB. Not sure if this is worth the effort .... if we do this, then we will need to add more special handling for Symbols in here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29869#discussion_r2865392569