JDK-7128632 : Memory leak in jdk1.7.0 (42 MB per day)
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2012-01-10
  • Updated: 2019-08-16
  • Resolved: 2012-03-06
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
7u4Resolved
Related Reports
Duplicate :  
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.7.0_02"
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) Server VM (build 22.0-b10, mixed mode)

FULL OS VERSION :
SunOS desna 5.10 Generic_141444-09 sun4u sparc SUNW,Sun-Fire-V490

A DESCRIPTION OF THE PROBLEM :
We've tried jdk 1.7.0_02. Ten days of running give 420 MB memory leak of the following objects:<BR>
- java.lang.management.MemoryUsage,<BR>
- [C (array of char),<BR>
- java.util.HashMap$Entry,<BR>
- [Ljava.util.HashMap$Entry (array of HashMap$Entry),<BR>
and some others.

This doesn't happen on jdk1.6.x.

First output of the "jmap -histo:live" command:

     num     #instances         #bytes  class name
    ----------------------------------------------
       1:        229527       14926888  [C
       2:        289290       13885920  java.lang.management.MemoryUsage
       3:        321029       10272928  java.util.HashMap$Entry
       4:         69923       10262184  <constMethodKlass>
       5:         69923        9527672  <methodKlass>
       6:          7048        7787040  <constantPoolKlass>
       7:        241693        7734176  java.lang.String
       8:          2038        5898408  [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
       9:          7048        5479056  <instanceKlassKlass>
      10:          5954        4499552  <constantPoolCacheKlass>
      11:         67844        4091672  [Ljava.util.HashMap$Entry;
      12:         41250        3942848  [B
      13:         65649        3151152  java.util.HashMap
      14:         71891        2875640  java.util.TreeMap$Entry
    ...
    Total       2320965      138000120

The last output of the "jmap -histo:live" command done in 10 days after the first:

     num     #instances         #bytes  class name
    ----------------------------------------------
       1:       3147110      151061280  java.lang.management.MemoryUsage
       2:       3178875      101724000  java.util.HashMap$Entry
       3:       1087332       53822632  [C
       4:       1099503       35184096  java.lang.String
       5:        639442       31529224  [Ljava.util.HashMap$Entry;
       6:        637247       30587856  java.util.HashMap
       7:        629422       25176880  [Ljava.lang.management.MemoryUsage;
       8:        314711       17623816  com.sun.management.GcInfo
       9:         70107       10292776  <constMethodKlass>
      10:        631864       10109824  java.util.HashMap$EntrySet
      11:        314711       10070752  sun.management.GcInfoCompositeData
      12:         70107        9552696  <methodKlass>
      13:          7075        7817080  <constantPoolKlass>
      14:        314713        7554128  [Ljava.lang.Integer;
      15:          2048        5898744  [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
      16:          7075        5497200  <instanceKlassKlass>
      17:        315792        5052672  java.lang.Integer
      18:         47680        4912352  [B
    ...
    Total      13206419      558217856

I also have 8 other histograms, made after each day of the tests. They show linear number of objects increasing. This is definitely not a noise. It is a stable leak 42 MB per day.

THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Did not try

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

REGRESSION.  Last worked in version 6u29

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Unfortunately, we haven't extracted the issues into a sample code. So far this is the whole our big product which reproduces the problem.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Move to the jdk 1.6.x
NOTE: if this is a critical customer issue it must go through customer support.