RFR(S): 8011724: G1: Stack allocate instances of HeapRegionRemSetIterator
John Cuthbertson
john.cuthbertson at oracle.com
Tue Apr 9 17:23:39 UTC 2013
Hi Bengt,
I changed the comment to:
// Indicates what granularity of table that we're currently iterating
over.
// We start iterating over the sparse table, progress to the fine grain
// table, and then finish with the coarse table.
// See HeapRegionRemSetIterator::has_next().
JohnC
On 4/8/2013 11:05 PM, Bengt Rutisson wrote:
>
> Hi John,
>
> Thanks for doing this cleanup! It really looks much better!
>
> Changes look good.
>
> One minor request if you feel like it:
>
> Since you anyway updated a comment in the class
> HeapRegionRemSetIterator. Could you also update (or just remove) this
> comment?
>
> // If true we're iterating over the coarse table; if false the fine
> // table.
> enum IterState {
> Sparse,
> Fine,
> Coarse
> };
>
> Also, have you measured any performance impact of this? I'm not
> suggesting that you should put any extra work into doing that. Just,
> in case you have some numbers, have you seen any improvements? I could
> imagine that there was a fair amount of false sharing going on with
> the old array of iterators, so I'm guess that we might see some perf
> improvements with this change. Just curious.
>
> Thanks,
> Bengt
>
> On 4/8/13 8:49 PM, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Can I have a couple of reviews of these changes:
>> http://cr.openjdk.java.net/~johnc/8011724/webrev.0 ?
>>
>> Summary:
>> I've changed RSet scanning to stack allocate instances of the
>> HeapRegionRemSet iterator and removed the pre-allocated instances
>> (created during heap initialization).
>>
>> Testing:
>> GC test suite with MaxTenuringThreshold=0, IHOP=1, and VerifyAfterGC
>> to create a lot of old data.; jprt.
>>
>> Thanks,
>>
>> JohnC
>
More information about the hotspot-gc-dev
mailing list