United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 7143760 Memory leak in GarbageCollectionNotifications
7143760 : Memory leak in GarbageCollectionNotifications

Details
Type:
Bug
Submit Date:
2012-02-08
Status:
Closed
Updated Date:
2012-03-24
Project Name:
JDK
Resolved Date:
2012-03-24
Component:
hotspot
OS:
generic,solaris_10
Sub-Component:
svc
CPU:
sparc,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
7,7u4
Fixed Versions:
hs23

Related Reports
Backport:
JDK-2221480 - Memory leak in GarbageCollectionNotifications
Backport:
JDK-2221519 - Memory leak in GarbageCollectionNotifications
Duplicate:
JDK-7128632 - Memory leak in jdk1.7.0 (42 MB per day)

Sub Tasks

Description
We found that when attached to a process with jconsole the value for "Used heap" was growing even though the main class of the attachee was a do-nothing-class (attached). The leak appeared to continue growing after jconsole was detached.

The leak did not reproduce with a recent HotSpot running on JDK6u29, so we looked at recent changes in src/classes/sun/management and tried un-applying e0c3fd538f1f
[ http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/e0c3fd538f1f ]

The leak did not reproduce when running with the change reverted so this particular change seems to be a likely culprit for the leak but we're not familiar enogh with the management classes to be able to see exactly where the leak occurs.

We looked at a hprof dump (attached) of the leaking process and found j.l.m.MemoryUsage at the top of the heap histogram with 98430 instances.

Comments
EVALUATION

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1891640ca63f
2012-03-22 
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1891640ca63f
2012-02-18 
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1891640ca63f
2012-02-18 
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1891640ca63f
2012-02-17 
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1891640ca63f
2012-02-14 
EVALUATION

There's a missing HandleMark at the beginning of the GCNotifier::sendNotificatin() method. Without this HandleMark, all handles used when creating MemoryUsage instances are kept alive causing a double leak: in the Java heap and in the thread local handle area of the service thread.

Suggested fix: adding the HandleMark:

void GCNotifier::sendNotification(TRAPS) {
  ResourceMark rm(THREAD);
  HandleMark hm(THREAD);                                 <----------
  GCNotificationRequest *request = getRequest();
  if(request != NULL) {
2012-02-09


Hardware and Software, Engineered to Work Together