RFR: 8158871: Long response times with G1 and StringDeduplication

[Stefan Johansson]

Looks good,
StefanJ

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