RFR(M/L): 7176479: G1: JVM crashes on T5-8 system with 1.5 TB heap

[Thomas Schatzl]

Hi,

On Mon, 2013-04-08 at 11:14 -0700, John Cuthbertson wrote:
> Hi Everyone,
> 
> I've synched up this webrev up with the latest changes in hotspot-gc and 
> made one additional refactoring change that was suggested offline. The 
> new webrev is at:
> 
> http://cr.openjdk.java.net/~johnc/7176479/webrev.2/
> 
> I'd like to use this webrev as the basis of some other refactoring work 
> I'd like to do in RSet updating and this will make it easier.

Could you make the two new globals unsigned (e.g. "uintx")? I do not see
a reason to even indicate the user that they may have negative values. I
saw the bounds check in the initialization code.

Minor: G1CardCounts::add_card_count() returns an int, while it cannot be
< 0. The count table elements are of type jbyte too (but then again it's
all private).

> > The new approach effectively undoes the previous mechanism and 
> > re-simplifies the card counts table.
> >
> > Summary of Changes:
> > The hot card cache and card counts table have been moved from the 
> > concurrent refinement code into their own files.

Good!

> >
> > The hot card cache can now exist independently of whether the counts 
> > table exists. In this case refining a card once adds it to the hot 
> > card cache, i.e. all cards are treated as 'hot'.

G1CardCounts::add_card_count() seems to return zero in this case, i.e.
not hot?

In G1CardCounts::resize() the code checks whether _card_counts == 0
(note that _card_counts is a pointer, so maybe the code should compare
to NULL instead), and in this method the code uses
_committed_max_card_num. Maybe extract this into a predicate
has_count_table() and use it uniformly?
Same in G1CardCounts::clear() and the destructor.

The asserts checking the consistency of _cards_counts,
_committed_max_card_num, and G1ConcRSHotCardLimit can then be moved
there instead of repeating them.

I don't consider checking G1ConcRSHotCardLimit important here because
the vm would not even start up when this is set wrongly.

> > Testing:
> > GC Test suite with MaxTenuringThreshold=0 (to increase the amount of 
> > refinement) and a low IHOP value (to force cleanups).
> > SPECjbb2005 with a 1.5TB heap size and 256GB young size, 
> > MaxTenuringThreshold=0 and a low IHOP value (1%). The systems team are 
> > continuing to test with very large heaps.

Any idea about performance differences or efficiency of the hot card
cache? (Maybe you mentioned that already).

Thomas