RFR (XS): Fix DerivedPointerTable handling when scanning roots twice in init-evac phase

Aleksey Shipilev shade at redhat.com
Tue Mar 7 15:01:18 UTC 2017

On 03/07/2017 03:59 PM, Roman Kennke wrote:
> Am 07.03.2017 um 12:30 schrieb Aleksey Shipilev:
>> On 03/07/2017 11:47 AM, Roman Kennke wrote:
>>> With my last fix, we're potentially scanning the roots twice: once for
>>> the initial-evacuation+update-refs, and if we run into OOM, another time
>>> to update remaining refs. This 2nd scan can cause problems in
>>> DerivedPointerTable: it asserts that every root is only visited once.
>>> This patch fixes it by enclosing each pass into DerivedPointerTable
>>> separately.
>>> http://cr.openjdk.java.net/~rkennke/fixdpt/webrev.00/
>> I don't get why do you need to duplicate update_pointers() call. Isn't it enough
>> to clear the table when concgc was cancelled, and then let the rest run its course?
>> if (cancelled_concgc()) {
>>   COMPILER2_PRESENT(DerivedPointerTable::clear());
>>   ...
>> }
>> COMPILER2_PRESENT(DerivedPointerTable::update_pointers());
> clear() checks that the DPT is not active. If we call clear() without
> having called update_pointers() before, we get this assert:
> #  Internal Error
> (/home/rkennke/src/openjdk/jdk9-shenandoah/hotspot/src/share/vm/compiler/oopMap.cpp:760),
> pid=1401, tid=1417
> #  assert(!_active) failed: should not be active
> (If I were to redesign DPT, I would make clear() and update_pointers() a
> scoped object...)

D'oh, okay then.

Put some comment about clear() should be preceded by update_pointers().


More information about the shenandoah-dev mailing list