RFR: 8183539: Remove G1RemSet::_into_cset_dirty_card_queue_set

Mikael Gerdin mikael.gerdin at oracle.com
Tue Jul 4 12:17:52 UTC 2017

Hi Erik,

On 2017-07-04 13:40, Erik Helin wrote:
> Hi all,
> here comes a simple patch (just removing code) with a quite complicated 
> justification :) So grab a cup of coffee, take out that good old pen and 
> paper (it is almost impossible to convince yourself that this is correct 
> without drawing) and enjoy the following little text:
> The G1RemSet::_into_cset_dirty_card_queue_set is no longer needed. It 
> was originally added to keep track of cards with pointer into the 
> collection set. In the case of evacuation failure, this set of cards 
> would then be enqueued for refinement in order to construct/update 
> remembered sets for regions that encountered evacuation failure (only 
> regions in the collection set can encounter evacuation failure). 
> However, this functionality is already provided by the call to 
> G1ParScanThreadState::update_rs and the evac failure handling code.
> For pointers in regions outside of the collection set pointing into the 
> collection set, we will always call G1ParScanThreadState::update_rs. 
> G1ParScanThreadState::update_rs will enqueue the card containing the 
> pointer pointing into the collection set onto 
> G1CollectedHeap::_dirty_card_queue_set. So 
> G1CollectedHeap::_dirty_card_queue_set will contain all the cards with 
> pointers into the collection set (that are not themselves in the 
> collection set). If an evacuation failure happens, then we will still 
> trace through the object graph, calling do_oop_evac (but do_oop_evac 
> will just return a pointer to the "from" object) for each object 
> pointing into the collection set. This means that all cards in regions 
> outside of the collection that contains pointers into the collection set 
> will end up on G1CollectedHeap::_dirty_card_queue_set.
> For pointers in regions in the collection set pointing into the 
> collection set, those will be handled by the evacuation failure handling 
> code. The evacuation failure handling code will iterate over all objects 
> in all regions that encountered an evacuation failure. If it encounters 
> an object with a forwarding pointer pointing to itself, then it will 
> enqueue the cards that contains that object's fields onto 
> G1CollectedHeap::_dirty_card_queue_set.
> The two above paragraphs means that after a collection, 
> G1CollectedHeap::_dirty_card_queue_set will always contain all cards 
> that contained pointers into the collection set. This is true for both a 
> successful collection and a collection that encountered evacuation 
> failure. However, these cards are exactly the cards that 
> G1RemSet::_into_cset_dirty_card_queue_set contains, so we might as well 
> remove the G1RemSet::_into_cset_dirty_card_queue_set.
> Patch: http://cr.openjdk.java.net/~ehelin/8183539/00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8183539
> Testing: make test TEST=hotspot_gc on Linux x86-64 fastdebug

Do you know if any of the tests actually would have failed if rem set 
reconstruction after evacuation failure didn't work properly?

I'd feel safer with this change if you ran with some verification code 
to ensure that the into_cset queue was always useless when evac failure 


> Thanks,
> Erik

More information about the hotspot-gc-dev mailing list