-
Bug
-
Resolution: Fixed
-
P2
-
1.4.2_27, 5.0u25, 6, 6u18, 6u20, 6u21, 6u23, 7
-
b102
-
generic, x86
-
generic, linux, solaris_10, windows_xp
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2213881 | 6u30 | Vaibhav Choudhary | P2 | Closed | Fixed | b08 |
JDK-2210716 | 6u29 | Vaibhav Choudhary | P2 | Closed | Fixed | b01 |
JDK-2212373 | 6u27-rev | Vaibhav Choudhary | P2 | Closed | Fixed | b20 |
JDK-2194332 | 6u26-rev | Vaibhav Choudhary | P2 | Resolved | Fixed | b22 |
JDK-2195048 | OpenJDK6 | Daniel Daugherty | P2 | Resolved | Fixed | b21 |
public static void main(String[] args) throws Exception {
while (true) {
java.util.logging.Logger.getAnonymousLogger();
Thread.sleep(1);
}
}
Here is the output of jmap command within a few seconds interval:
user@t1007:~> jmap -d64 -histo:live 29201|grep WeakReference
8: 22493 1079664 java.lang.ref.WeakReference
31: 1 32144 [Ljava.lang.ref.WeakReference;
106: 17 952
com.sun.jmx.mbeanserver.WeakIdentityHashMap$IdentityWeakReference
user@t1007:~> jmap -d64 -histo:live 29201|grep WeakReference
8: 23191 1113168 java.lang.ref.WeakReference
31: 1 32144 [Ljava.lang.ref.WeakReference;
103: 17 952
com.sun.jmx.mbeanserver.WeakIdentityHashMap$IdentityWeakReference
user@t1007:~> jmap -d64 -histo:live 29201|grep WeakReference
8: 23804 1142592 java.lang.ref.WeakReference
31: 1 32144 [Ljava.lang.ref.WeakReference;
103: 17 952 com.sun.jmx.mbeanserver.WeakIdentityHashMap$IdentityWeakReference
Note that jmap command forces FullGC.
More on http://forums.java.net/jive/thread.jspa?threadID=75651&tstart=0
The forum thread has an additional posting that clarifies the APIs
used by the real application:
Just more information about the issue.
The code above is just an artificial piece of code which easily reproduces the problem.
In the live system the allocation call tree looks like:
...
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(ObjectName name, String attribute)
...
com.sun.jmx.trace.TraceManager.getLogger(int type)
java.util.logging.Logger.getLogger(String name)
In 6 days the number of WeakReference instances grows up to 240 000 (11 Mb). So the increase is 2 Mb per day.
The issue is reproduced on Linux and Solaris.
Linux version:
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
Linux rhone 2.6.18-128.1.14.el5 #1 SMP Mon Jun 1 15:52:58 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Solaris version:
Solaris 10 11/06 s10s_u3wos_10 SPARC
Copyright 2006 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 14 November 2006
- backported by
-
JDK-2194332 Memory leak of java.lang.ref.WeakReference objects
- Resolved
-
JDK-2195048 Memory leak of java.lang.ref.WeakReference objects
- Resolved
-
JDK-2210716 Memory leak of java.lang.ref.WeakReference objects
- Closed
-
JDK-2212373 Memory leak of java.lang.ref.WeakReference objects
- Closed
-
JDK-2213881 Memory leak of java.lang.ref.WeakReference objects
- Closed
- duplicates
-
JDK-6949855 OutOfMemory on JDK 1.6.0_18, 1.6.0_19 and 1.6.0_20, suspected java.util.logging
- Closed
-
JDK-6931561 LogManager still causes a memory leak
- Closed
-
JDK-7020446 Logger Memory Leak
- Closed
- relates to
-
JDK-6964059 LogManager's singleton nature should be enforced
- Closed
-
JDK-6274920 JDK logger holds strong reference to java.util.logging.Logger instances
- Closed
-
JDK-6964018 AnonLoggerWeakRefLeak and LoggerWeakRefLeak can fail in JPRT
- Closed
-
JDK-6968401 disable tests added by 6942989 until 6964018 is fixed
- Closed
-
JDK-6971847 jmap '-histo:live' option is necessary for proper leak detection
- Closed