RFR: 8261859: gc/g1/TestStringDeduplicationTableRehash.java failed with "RuntimeException: 'Rehash Count: 0' found in stdout" [v2]

Kim Barrett kbarrett at openjdk.java.net
Mon Mar 1 10:30:13 UTC 2021


On Mon, 1 Mar 2021 09:58:37 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 411:
>> 
>>> 409:     size_t needed = _table->_entries / _shrink_load_factor;
>>> 410:     if (needed > _min_size) {
>>> 411:       size = round_down_power_of_2(needed);
>> 
>> Unfortunately, aggressive shrinking can't be done without other changes.
>> The current resizing code assumes shrinking is only by a factor of 2,
>> because of the way segments are claimed.  Shrinking could probably be
>> adjusted to deal with larger factors, but I think that's outside the scope
>> of what's needed for this change.  (Growth by an arbitrary power of 2
>> doesn't seem to be a problem.)  Fixing...
>
> I agree that it should be a separate change as long as the test failure is fixed. But I guess adjusting the grow should be enough to make the test pass, right?

I think so, barring something pretty strange happening.

The initial table size is _min_size.  With the old growth calculation, if
the table gets big enough quickly enough then there will be enough growth
steps to occupy all of the collections and processing the test performs and
there won't be any rehashes, leading to test failure.  With the new
calculation, since the test program stops allocating a significant number of
strings before running the test GCs, the size will jump and then remain
stable for some rehashes to get in.  If a lot of deduped strings were
dropped so that many shrink steps were needed, that could break the test,
but the test doesn't do that, and it seems unlikely that would happen for
environmental or other reasons.

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

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



More information about the hotspot-gc-dev mailing list