RFR(S): 7121547: G1: High number mispredicted branches while iterating over the marking bitmap

[Tony Printezis]

John,

Please update the copyright year in bitMap.inline.hpp.

Stylistic issues:

   31 inline bool CMBitMapRO::iterate(BitMapClosure* cl, MemRegion mr) {
   32   HeapWord* left  = MAX2(_bmStartWord, mr.start());
   33   HeapWord* right = MIN2(_bmStartWord + _bmWordSize, mr.end());
   ...


   55 inline bool CMBitMapRO::iterate(BitMapClosure* cl) {
   56   MemRegion mr(startWord(), sizeInWords());
   ...


Could you use in both cases either startWord() / sizeInWords() or 
_bmStartWord / _bmWordSize to be consistent? I had to go and check that 
the two were the same.

Also, instead of left / right and start / end can you maybe use 
start_addr / end_addr and start_index / end_index to make the code a bit 
clearer?

Regarding the weakening of the assert: I wonder why we haven't come 
across it before. I can only assume that so far iterations that have 
used this method have only given ranges that were aligned on bitmap word 
boundaries (if I understand correctly what the issue is!)? Can you maybe 
tighten it up a bit? I.e., if r_offset is bitmap word aligned -> 
res_offset < r_offset, otherwise -> res_offset < size()?

Did analyzer show whether do_bit() is now getting inlined?

Tony

On 12/20/2011 12:46 PM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers review this small change? The webrev 
> can be found at: http://cr.openjdk.java.net/~johnc/7121547/webrev.0/
>
> Summary:
> While analyzing the data from some collect/analyze runs of the changes 
> for 6484965 (Piggy back liveness accounting on marking) it was noticed 
> that there was a significant number of mispredicted branches 
> associated with the actual call of BitMap::iterate() from within 
> CMBitMapRO::iterate(). With the changes in the webrev I can see a 
> slight reduction in the CPU time (a few percentage points), a slight 
> reduction in the number of L2 misses (again a few points), and between 
> a 20-40% drop in the number of mis-predicted branches.
>
> Testing: The GC test suite and Kitchensink (with low marking 
> thresholds); collect/analyze runs of SPECjbb2005; jprt.
>
> Thanks,
>
> JohnC