RFR(s): 8205583: Crash in ConcurrentHashTable do_bulk_delete_locked_for
Robbin Ehn
robbin.ehn at oracle.com
Tue Jun 26 09:13:23 UTC 2018
Hi Gerard,
On 06/25/2018 09:03 PM, Gerard Ziemski wrote:
> hi Robbin,
>
> Looks good, a few comments:
Thanks,
>
> #1 In stringTable.cpp no need for line:
>
> 502 bool interrupted = false;
Fixed
>
> #2 In concurrentHashTableTasks.inline.hpp, can’t we name the method as “continue”?
>
> 108 void cont(Thread* thread) {
As Kim said, reserved.
>
> #3 In concurrentHashTableTasks.inline.hpp, I noticed that we grab “_resize_lock” for stuff like bulk delete, so should we rename it to “_task_lock”, or something else that describes its purpose better? (in a new RFR)
Yes
>
> 123 BulkDeleteTask(ConcurrentHashTable<VALUE, CONFIG, F>* cht, bool is_mt = false)
> 124 : BucketsOperation(cht, is_mt) {
> 125 }
> 126 // Before start prepare must be called.
> 127 bool prepare(Thread* thread) {
> 128 bool lock = BucketsOperation::_cht->try_resize_lock(thread);
>
> #4 If we must get “thread_owns_resize_lock” before we call “ setup”, can we enforce it, by calling "thread_owns_resize_lock” from “setup”, or at least should we have assert in “setup” checking that we have the lock?
Moved it.
/Robbin
>
> 132 this->thread_owns_resize_lock(thread);
> 133 this->setup();
>
>
> cheers
>
>> On Jun 25, 2018, at 1:26 PM, Robbin Ehn <robbin.ehn at oracle.com> 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