RFR: 8254598: StringDedupTable should use OopStorage

Kim Barrett kbarrett at openjdk.java.net
Sat May 1 09:48:53 UTC 2021


On Wed, 28 Apr 2021 00:29:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/classfile/stringTable.cpp line 784:
>> 
>>> 782:   SharedStringIterator iter(f);
>>> 783:   _shared_table.iterate(&iter);
>>> 784: }
>> 
>> So with this change (somewhere below) do you no longer deduplicate strings from the shared string table? ie
>> 
>> // The CDS archive does not include the string deduplication table. Only the string
>> // table is saved in the archive. The shared strings from CDS archive need to be
>> // added to the string deduplication table before deduplication occurs. That is
>> // done in the beginning of the StringDedupThread (see StringDedupThread::do_deduplication()).
>> void StringDedupThread::deduplicate_shared_strings(StringDedupStat* stat) {
>>   StringDedupSharedClosure sharedStringDedup(stat);
>>   StringTable::shared_oops_do(&sharedStringDedup);
>> }
>> Asking @iklam to have a look then.
>
> If I understand correctly, we no longer need to add the entire set of shared strings into the dedup table.
> 
> 
> +// As a space optimization, when shared StringTable entries exist the shared
> +// part of the StringTable is also used as a source for byte arrays.  This
> +// permits deduplication of strings against those shared entries without
> +// recording them in this table too.
> +class StringDedup::Table : AllStatic {
> 
> ...
> 
> +void StringDedup::Table::deduplicate(oop java_string) {
> +  assert(java_lang_String::is_instance(java_string), "precondition");
> +  _cur_stat.inc_inspected();
> +  if ((StringTable::shared_entry_count() > 0) &&
> +      try_deduplicate_shared(java_string)) {
> +    return;                     // Done if deduplicated against shared StringTable.

Ioi is correct; we deduplicate "directly" against the shared string table rather than adding the shared strings to the deduplication table.

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

PR: https://git.openjdk.java.net/jdk/pull/3662


More information about the core-libs-dev mailing list