RFR: 8202083: Remove explicit CMS checks in CardTableBarrierSet

Erik Osterlund erik.osterlund at oracle.com
Fri Apr 27 16:57:19 UTC 2018


Hi Kim,

Thanks for the review.

/Erik

On 27 Apr 2018, at 18:53, Kim Barrett <kim.barrett at oracle.com> wrote:

>> On Apr 27, 2018, at 4:41 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
>> 
>> Hi Kim,
>> 
>> Now that we reached an agreement on 8202082, may I assume we have reached an agreement here too?
> 
> Oh, right.  Yes.  Just needs the comment fix.
> 
>> 
>> Thanks,
>> /Erik
>> 
>> On 2018-04-23 23:29, Kim Barrett wrote:
>>>> On Apr 20, 2018, at 10:50 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> In CardTableBarrierSet, we sometimes need fencing due to the card table being scanned concurrently when using CMS with pre-cleaning. Rather than explicitly checking for those CMS flags in the generic CardTableBarrierSet class, it is preferrable to check the CardTable scanned_concurrently() property which reflects that better
>>>> 
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~eosterlund/8202083/webrev.00/
>>>> 
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8202083
>>>> 
>>>> Thanks,
>>>> /Erik
>>> Isn't the correct predicate here
>>> CardTableBarrierSet::card_mark_must_follow_store?
>>> 
>>> Also, the comment probably ought to be "generalized".
>>> 
>>> Also, CardTable::scanned_concurrently() seems misplaced. CardTable is
>>> a data structure, scanned_concurrently is a usage policy. And the only
>>> use of scanned_concurrently seems to be the implementation of
>>> card_mark_must_follow_store. It seems like CardTableBarrierSet would
>>> be a better place for that bit of information.
> 
> 




More information about the hotspot-gc-dev mailing list