RFR(s): 8205583: Crash in ConcurrentHashTable do_bulk_delete_locked_for

[Kim Barrett]

> On Jun 25, 2018, at 3:30 PM, coleen.phillimore at oracle.com wrote:
> 
> 
> Hi Robbin, This change seems good. I agree with Gerard's comment about s/cont/continue/ which would be a small change to this bug fix.

“continue” is a reserved word.

> 
> And I agree with the request for a future RFE to rename _resize_lock since it's used for bulk deletion.
> 
> thanks,
> Coleen
> 
> 
> On 6/25/18 2:26 PM, Robbin Ehn wrote:
>> Hi all, please review.
>> 
>> Webrev: http://cr.openjdk.java.net/~rehn/8205583/v0/webrev/index.html
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8205583
>> 
>> The problem is that the cancel-able cleaning operation is unaware of rehash.
>> The cleaning starts, pauses for a safepoint which does the rehash, destroying
>> the old table. When the cleaning continues after the safepoint it will continue
>> to do so in the destroyed table.
>> 
>> The cancelability of the cleaning operation is not needed and just creates
>> complicity. In this change-set I remove that functionality, which means a rehash
>> will be postponed until the cleaning have finished. (identical as for growing)
>> 
>> Passed 700 runs of the test that produced the error and tier 1-3.
>> 
>> Thanks, Robbin