RFR(s): 8205583: Crash in ConcurrentHashTable do_bulk_delete_locked_for
David Holmes
david.holmes at oracle.com
Tue Jun 26 01:32:30 UTC 2018
Hi Robbin,
Do you have any idea on what exact circumstances caused this bug to be
exposed? I'm a little concerned that my mach5 testing accidentally
tripped over it while our proper testing has not!
Thanks,
David
On 26/06/2018 4:26 AM, 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
More information about the hotspot-runtime-dev
mailing list