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

[Ioi Lam]

On Tue, 21 Feb 2023 15:54:54 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> 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?

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.

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

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