JDK-7152954 : G1: Native memory leak during full GCs
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs23,7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,linux_redhat_5.0
  • CPU: generic,x86
  • Submitted: 2012-03-12
  • Updated: 2013-09-18
  • Resolved: 2012-03-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u4Fixed 8Fixed hs23Fixed
Description
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. Will need to look closer at this to figure out if it is the correct solution. But the current fix confirms that this is indeed the source of the memory leak.

Comments
EVALUATION http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/b7175879a006
20-03-2012

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2c0751569716
17-03-2012

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2c0751569716
14-03-2012

EVALUATION See description.
12-03-2012