RFR: 8376822: UseCompactObjectHeaders: fill Klass alignment gaps in AOT cache [v2]
Ioi Lam
iklam at openjdk.org
Wed Feb 25 18:24:40 UTC 2026
On Tue, 24 Feb 2026 11:12:39 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:
>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>>
>> moved offset != 0 check
>
> src/hotspot/share/cds/archiveUtils.cpp line 293:
>
>> 291: using AllocGapNode = RBNode<DumpRegion::AllocGap, Empty>;
>> 292:
>> 293: class DumpRegion::AllocGapTree : public RBTreeCHeap<AllocGap, Empty, AllocGapCmp, mtClassShared> {
>
> Is there a reason that we're subclassing here instead of having a RBTreeCHeap as a member of this class?
Since I named the class `AllocGapTree`, I think subclassing makes more sense.
> src/hotspot/share/cds/archiveUtils.cpp line 310:
>
>> 308: }
>> 309:
>> 310: char* allocate_from_gap(size_t num_bytes) {
>
> `precond` that `num_bytes` is divisble by `SharedSpaceObjectAlignment`?
The condition is checked inside the `AllocGap` constructor just below this line. I do the `preconds` there to avoid sprinkling alignment checks all over the code.
> src/hotspot/share/cds/archiveUtils.cpp line 318:
>
>> 316: AllocGapNode* node = closest_ge(target);
>> 317: if (node == nullptr) {
>> 318: return nullptr; // Didn't find any useable gap.
>
> Sp nit: 'usable' is preferred
Fixed.
> src/hotspot/share/cds/archiveUtils.cpp line 373:
>
>> 371: if (alignment == SharedSpaceObjectAlignment && type != MetaspaceClosureType::SymbolType) {
>> 372: // The addresses of Symbols must be in the same order as they are in ArchiveBuilder::SourceObjList.
>> 373: // If we put them in gaps, their orders will change.
>
> "orders" -> "order"
Fixed.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29869#discussion_r2854632657
PR Review Comment: https://git.openjdk.org/jdk/pull/29869#discussion_r2854633466
PR Review Comment: https://git.openjdk.org/jdk/pull/29869#discussion_r2854633176
PR Review Comment: https://git.openjdk.org/jdk/pull/29869#discussion_r2854634033
More information about the hotspot-dev
mailing list