Request for review (S): 7152954 G1: Native memory leak during full GCs

Bengt Rutisson bengt.rutisson at oracle.com
Mon Mar 12 09:36:33 UTC 2012


Hi all,

Could I have a couple of reviews for this fairly small change:

http://cr.openjdk.java.net/~brutisso/7152954/webrev.00/

The CR will be publicly available soon here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152954


I choose to do a fairly small fix. To me it looks like the SurvRateGroup 
class could benefit from some refactoring. Maybe this hole issue could 
go away with some simplifications to the code. But I'd like to keep the 
change as small as possible for now just in case we would like to push 
this into hs23.


Background from the CR:

There is a memory leak in the full GC code for G1. This can be seen by 
running this simple reproducer:

public class SysGC {
     public static void main(String[] args) {
         while (true) {
             System.gc();
         }
     }
}

I run it with this command line:

java -XX:+UseG1GC -Xms16m -Xmx16m -XX:+PrintGC SysGC

Watching the memory footprint for the java process shows that it is 
constantly using more memory.

The leak comes from SurvRateGroup::stop_adding_regions() which is called 
from SurvRateGroup::reset(), which in turn is called from 
G1CollectorPolicy::record_full_collection_end().

The problem with SurvRateGroup::stop_adding_regions() is that it does:

_surv_rate_pred[i] = new TruncatedSeq(10);

in a loop every time it is called. But there is no corresponding call to 
delete.

Adding a loop to call delete on the previously allocated TruncatedSeq 
objects is not enough to solve the problem since TruncatedSeq is itself 
allocating an array without freeing it. Adding a destructor to 
TruncatedSeq that frees the allocated array solves the issue.

With these two fixes the memory leak seems to go away.

Thanks,
Bengt



More information about the hotspot-gc-dev mailing list