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

[Ashutosh Mehra]

On Tue, 21 Feb 2023 04:10:47 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:
> 
>   @dholmes-ora comments

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

> 129:   //           [bits 31 .. 14][ bits 13 .. 0  ]
> 130:   //            primary_index  secondary_index
> 131:   const static int _secondary_array_index_bits = 14;

I am sure secondary array bits are selected such that the secondary array is less than `ArchiveHeapWriter::MIN_GC_REGION_ALIGNMENT`.
But I believe it would make the code more robust if we calculate the secondary array length dynamically by determining the appropriate length of the array for a given size.
For instance by querying `objArrayOopDesc` for the appropriate length of the array for an object of `ArchiveHeapWriter::MIN_GC_REGION_ALIGNMENT` bytes, and then set the `_secondary_array_index_bits` according to the result.
It would also alleviate the problem of how to best divide the 32 bits between secondary and primary array.
Does that make sense?

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

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