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