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

[Ioi Lam]

On Fri, 27 Feb 2026 14:43:59 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> src/hotspot/share/cds/archiveUtils.cpp line 371:
>> 
>>> 369: #endif
>>> 370: 
>>> 371:   if (alignment == SharedSpaceObjectAlignment && type != MetaspaceClosureType::SymbolType) {
>> 
>> Since the gaps are in rw region only, shouldn't we use the gaps only when `read_only` is false?
>
> Another way to avoid storing `read_only` objects in `rw` region gaps, assuming we want to do that,  would be  to have a `_gap_tree` as an instance field in each `DumpRegion`.  It would be nullptr for every region other than `rw` region. And then `allocate_metaspace_obj` would attempt to allocate in gaps only if `_gap_tree` is not null.

The reason to also allocate RO objects in the gaps is because we don't have enough small RW object to fill all the gaps. If I add `&& !read_only` in line 371:


[7.207s][warning][aot] Unexpected 836 gaps (17520 bytes) for Klass alignment
[7.207s][info   ][aot] Allocated 7665 objects of 748112 bytes in gaps (remain = 17520 bytes)


It's OK to allocate RO objects in the gaps. We don't require RO object to be mmaped read-only -- e.g., we don't try to write into them and expect a memory fault to trigger some sort of exception handling.

The JVM promises to never write into the RO objects, so that it's possible to mmap the RO region in read-only mode so that it can be easily shared across processes. This is beneficial mostly on Windows only, as on Unix platforms even the RW region can be shared with copy-on-write.

In any case, now that we are doing pointer relocation for ASLR, the RO region is usually mapped in read-write mode.

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

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