RFR: 8158871: Long response times with G1 and StringDeduplication

Stefan Johansson stefan.johansson at oracle.com
Tue Jun 14 13:20:44 UTC 2016

Looks good,

On 2016-06-14 14:18, Per Liden wrote:
> Hi,
> Received some comments off-line and here's an updated webrev:
> http://cr.openjdk.java.net/~pliden/8158871/webrev.1/
> Main difference is that the overflow list now lives next to the cache 
> list, rather than inside the cache list.
> thanks,
> Per
> On 2016-06-13 12:19, Per Liden wrote:
>> Hi,
>> Could I please have a couple of reviews in this bug fix.
>> Summary: When entries are pruned from the StringDedupTable, the actual
>> freeing of those entries are done while both holding the
>> StringDedupTable_lock and being joined to the SuspendibleThreadSet. This
>> causes both String.intern() and safepoints to be blocked until the
>> freeing is completed. As described in the bug report, this can cause a
>> very noticeable hick up in application response times when a huge amount
>> (millions) of entries are pruned at once. The patch fixes this by moving
>> all freeing out from the StringDedupTable_lock and the
>> SuspendibleThreadSet is only joined temporarily to bulk-extract the list
>> of entries to free, which is an O(1) operation.
>> Webrev: http://cr.openjdk.java.net/~pliden/8158871/webrev.0/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8158871
>> Testing: All jtreg string dedup tests pass. Manually provoked the
>> problematic condition and verified that the actual freeing of entries
>> doesn't block safepoints or String.intern().
>> thanks,
>> Per

More information about the hotspot-gc-dev mailing list