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

[Ashutosh Mehra]

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

>> 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?
>
> I wanted `_secondary_array_index_bits` to be a compile-time constant so that the related code can be optimized by the C++ compiler. However, to calculate it at compile time would require the use of `constexpr`, but `objArrayOopDesc::object_size(int)` can't easily be made `constexpr` because it eventually reads the runtime constant `heapOopSize`.
> 
> Instead, I added a function `StringTable::verify_secondary_array_index_bits()` to check that its value isn't too big.
> 
> Note that I used 14 as that will be the eventually value when we support Shenandoah. Also, using a large value means the SharedStringsStress needs a larger data set, so I stick with 14.
> 
> This will still support up to 28M strings so it's should be OK.

@iklam  thanks for adding those comments in `StringTable::verify_secondary_array_index_bits`.

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

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