RFR: 8356125: Interned strings are omitted from AOT cache
Ioi Lam
iklam at openjdk.org
Tue May 6 23:05:13 UTC 2025
On Tue, 6 May 2025 17:08:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> When dumping the interned string table in the AOT cache, we try to include only the strings that are inside ConstantPool::reference_array(). The hope is to limit the size of the AOT cache by omitting interned strings that are not used by objects inside the AOT cache.
>>
>> However, we have found two cases when the above scheme doesn't work. Please see the new test cases.
>>
>> The fix is to always include all interned strings managed by stringTable.cpp. We might try to omit the truly unused strings in a separate RFE.
>
> src/hotspot/share/cds/heapShared.cpp line 609:
>
>> 607:
>> 608: void HeapShared::archive_strings() {
>> 609: oop shared_strings_array = StringTable::init_shared_strings_array();
>
> I see the old comment here that we always succeed, because `StringTable::init_shared_table` does not create any large arrays. Is this still true? I see this in `StringTable::allocate_shared_strings_array`:
>
>
> if (ArchiveHeapWriter::is_too_large_to_archive(secondary_array_size)) {
> // This can only happen if you have an extremely large number of classes that
> // refer to more than 16384 * 16384 = 26M interned strings! Not a practical concern
> // but bail out for safety.
> log_error(cds)("Too many strings to be archived: %zu", _items_count);
> MetaspaceShared::unrecoverable_writing_error();
> }
>
>
> If we archive the _entirety_ of `StringTable` now, then it is plausible we could archive > 26M Strings now? Maybe write a stress test to see that we are properly failing out of that? Can be (should be?) a follow-up.
Yes, the object returned by `StringTable::init_shared_strings_array()` will never reach any object that's too large to archive.
We don't allow arbitrary user code to execute when we dump the heap (either `java -Xshare:dump` or `java -XX:AOTMode=create`). So the number of interned strings will be basically be limited to how many string literals you can fit into classfiles.
There will be some wastage, but this is mostly from string literals from classes that have been excluded.
It should be fairly straight forward to eliminated the unreferenced interned strings -- modify AOTArtifactFinder to walk everything else except the interned string table. Afterwards, scan the interned string table and omit the strings that have not been picked up yet.
This doesn't seem a big problem so we will probably do it after 25.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25026#discussion_r2076483766
More information about the hotspot-dev
mailing list