[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-gc-dev
Subject:    Re: RFR: 8030646: Track collection set membership in one place
From:       Kim Barrett <kim.barrett () oracle ! com>
Date:       2015-01-30 22:53:10
Message-ID: CAE06CD5-D738-4284-A3AB-E6506D6D43BD () oracle ! com
[Download RAW message or body]

On Jan 26, 2015, at 6:02 AM, Erik Helin <erik.helin@oracle.com> wrote:
> 
> Hi all,
> 
> this (rather) small patch removes the field
> HeapRegion::_in_collection_set and instead only uses the
> G1BiasedMappedArray G1CollectedHeap::_in_cset_fast_test to track
> collection set membership. Given that _in_cset_fast_test already track
> collection set membership, the _in_collection_set field in HeapRegion is
> redundant, it is only messy to keep track of this information in two
> places.
> 
> Patch:
> http://cr.openjdk.java.net/~ehelin/8030646/webrev.00/
> 
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8030646

Coming in late:

In the comments for JDK-8027959
https://bugs.openjdk.java.net/browse/JDK-8027959
Early reclamation of large objects in G1

Thomas said:

------------------------------------------------------------------------------
> In reply to the previous comment:
>
> Putting the humongous objects (even temporarily) into the collection
> set gives issues with remembered set updates not occurring any more.
>
> Current prototype changes in_cset_fast_test to include humongous
> objects (

There are no issues with remembered set updates when temporarily
putting the humongous object into the _in_cset_fast_test collection
set test because during rset update we use the _in_collection_set
member of the heapregion, not the in_cset_fast_test.
------------------------------------------------------------------------------

But this proposed change for JDK-8030646
https://bugs.openjdk.java.net/browse/
Track collection set membership in one place

would eliminate _in_collection_set in favor of always using
in_cset_fast_test.  That would seem to break an assumption on which
the earlier JDK-8027959 change is based.

[prev in list] [next in list] [prev in thread] [next in thread]