RFR: 8301106 allow cds interned strings to be moved by gc [v4]

David Holmes dholmes at openjdk.org
Wed Mar 1 05:32:10 UTC 2023


On Tue, 21 Feb 2023 21:49:08 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> **Background:**
>> 
>> Currently, the archived java strings are mapped in the G1 "[closed archive](https://github.com/openjdk/jdk/blob/574b48c6925ebfb31345fc46c7d23aa4153f99b0/src/hotspot/share/gc/g1/heapRegionType.hpp#L80-L92)" region. This essentially pins all the strings in memory.
>> 
>> As a prerequisite for  ([JDK-8296263](https://bugs.openjdk.org/browse/JDK-8296263)), this PR removes the requirement of pinning the archived strings. This will allow the CDS archive heap to be mapped in garbage collectors that do not support object pinning.
>> 
>> **Code changes:**
>> 
>> - The archived strings are referenced through an objArray (`_shared_strings_array`) to keep them alive. As a result, it's no longer necessary to pin them.
>> - Since it's possible for the GC to move these strings, the `_shared_table` in stringTable.cpp is modified to store a 32-bit index for each archived string. This index is used to retrieve the archived string from `_shared_strings_array` at runtime.
>> 
>> Note that CDS has a limit on the size of archived objArrays. When there's a large number of strings, we use a two-level table. See the comments around  `_shared_strings_array` in the header file.
>> 
>> **Testing**
>> 
>> Tiers 1 - 4
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @ashu-mehra and @dholmes-ora review -- better assert and error checking for large objects; added StringTable::verify_secondary_array_index_bits()

src/hotspot/share/classfile/stringTable.hpp line 136:

> 134: 
> 135:   // make sure _secondary_array_index_bits is not too big
> 136:   static void verify_secondary_array_index_bits() PRODUCT_RETURN;

This needs to be NOT_DEBUG_RETURN, as the function definition is DEBUG only.

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

PR: https://git.openjdk.org/jdk/pull/12607


More information about the hotspot-runtime-dev mailing list