RFR: 8376125: Out of memory in the CDS archive error with lot of classes

Alexey Bakhtin abakhtin at openjdk.org
Tue Feb 3 00:41:00 UTC 2026


On Sun, 1 Feb 2026 04:34:02 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> There are two more apis that return "unchecked" offset:  `ArchiveBuilder::buffer_to_offset()` and `ArchiveBuilder::any_to_offset()`. These apis are not returning the scaled offset. I think it is better to get rid of these apis and replace their usage with `_u4` version which has the offset range check. I noticed there are only 1-2 instances that use these "unchecked" apis.
>
>> There are two more apis that return "unchecked" offset: `ArchiveBuilder::buffer_to_offset()` and `ArchiveBuilder::any_to_offset()`. These apis are not returning the scaled offset. I think it is better to get rid of these apis and replace their usage with `_u4` version which has the offset range check. I noticed there are only 1-2 instances that use these "unchecked" apis.
> 
> Thanks for the suggestion. I looked into this and found that buffer_to_offset() and any_to_offset() serve a different purpose than the _u4 versions. The _u4 versions use scaled encoding (with MetadataOffsetShift) and return a compact u4 for metadata pointer storage. The raw versions return unscaled byte offsets stored in larger types.  These usages cannot switch to _u4 versions because they need raw byte offsets (not scaled) and store them in 64-bit types.
> 
> However, the comments for the methods may be misleading after introducing the _u4 methods.  What do you think to revise the comment as:
> 
> // The address p points to an object inside the output buffer. When the archive is mapped
> // at the requested address, what's the byte offset of this object from _requested_static_archive_bottom?
> uintx buffer_to_offset(address p) const;
> 
> // Same as buffer_to_offset, except that the address p points to either (a) an object
> // inside the output buffer, or (b), an object in the currently mapped static archive.
> uintx any_to_offset(address p) const;
> 
> // The reverse of buffer_to_offset_u4() - converts scaled offset units back to buffered address.
> address offset_to_buffered_address(u4 offset_units) const;
> 
> 
> I am also OK to rename the method names to: `buffer_to_offset_bytes()` and `any_to_offset_bytes()`, if the new names are clearer.
> 
> @ashu-mehra What do you think?

Hi @XueleiFan,

I've tried the suggested code with an archive size more than 4Gb, but it fails with an assertion:

#  Internal Error (aotMetaspace.cpp:1955), pid=96332, tid=4099
#  guarantee(archive_space_size < max_encoding_range_size - class_space_alignment) failed: Archive too large

CDC archive was created successfully:

[187.068s][info   ][cds    ] Shared file region (rw) 0: 822453584 bytes, addr 0x0000000800004000 file offset 0x00004000 crc 0x132b652e
[189.176s][info   ][cds    ] Shared file region (ro) 1: 3576115584 bytes, addr 0x0000000831060000 file offset 0x31060000 crc 0x71b020a2
[197.653s][info   ][cds    ] Shared file region (ac) 4:        0 bytes
[198.870s][info   ][cds    ] Shared file region (bm) 2: 56555664 bytes, addr 0x0000000000000000 file offset 0x1062d4000 crc 0xbd87f804
[199.504s][info   ][cds    ] Shared file region (hp) 3: 16091256 bytes, addr 0x00000000ff000000 file offset 0x1098c4000 crc 0x7834b7c3
[199.684s][debug  ][cds    ] bm space:  56555664 [  1.3% of total] out of  56555664 bytes [100.0% used]
[199.684s][debug  ][cds    ] hp space:  16091256 [  0.4% of total] out of  16091256 bytes [100.0% used] at 0x0000000c6d000000
[199.684s][debug  ][cds    ] total   : 4471216088 [100.0% of total] out of 4471228536 bytes [100.0% used]

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

PR Comment: https://git.openjdk.org/jdk/pull/29494#issuecomment-3838062386


More information about the hotspot-dev mailing list