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