RFR(S): 8204857: ConcurrentHashTable: Fix parallel processing

Gerard Ziemski gerard.ziemski at oracle.com
Fri Jun 15 15:31:29 UTC 2018

hi Robbin,

Looks OK.

Two questions though

#1 what is the purpose of the code (line 1003):

    for (uintptr_t v = 1; v < 99999; v++ ) {
      TestLookup tl(v);
      cht->get_copy(this, tl);

Is it to “interfere” with the multithreaded delete operation? If so, I guess we can’t put any asserts around "cht->get_copy(this, tl);” as some items might be deleted and some not at that point?

#2 I don’t see how the parallel task split the work to cooperate - is it really useful to have bulk_delete with threads that have the same evaluators? Wouldn’t the threads be competing with each other, rather that dividing the task and cooperating?


> On Jun 13, 2018, at 5:48 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
> On 06/12/2018 08:14 PM, coleen.phillimore at oracle.com wrote:
>> This looks good.
> Thanks!
>> http://cr.openjdk.java.net/~rehn/8204857/webrev/test/hotspot/gtest/utilities/test_concurrentHashtable.cpp.frames.html 1018 EXPECT_TRUE(false) << "Not items should left";
>> Little typo.
> Fixed!
> /Robbin
>> Thanks,
>> Coleen
>> On 6/12/18 10:51 AM, Robbin Ehn wrote:
>>> Hi, please review,
>>> The parallel processing functionality of the concurrenthastable is not working.
>>> This adds a gtest for it and fixes the issue. But there are no users of it, so the most important is the gtest so we don't breaks this in the future.
>>> Change-set: http://cr.openjdk.java.net/~rehn/8204857/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204857
>>> /Robbin

More information about the hotspot-runtime-dev mailing list