P3
FULL PRODUCT VERSION :
Java version " 1.7.0_06 "
Java(TM) SE Runtime Environment (build 1.7.0_06-b24)
Java HotSpot(TM) 64-Bit Server VM (build 23.2-b09, mixed mode)
I have the same problem on 1.7.0_15 and 1.7.0_5.
FULL OS VERSION :
CentOS 5.6 2.6.18-238.el5 x86_64
A DESCRIPTION OF THE PROBLEM :
If I attach JMX-Console to my application the JVM will start to leak strings. About 3 strings per GC cycle I've estimated. If I disconnect JConsole, the VM will continue to leak strings. If I start a fresh test and never connect JConsole it never leaks, but once you connect it once it leaks for the life of the process. I'll a process restart solves the problem.
Currently using Concurrent Mark & Sweep GC (default when on a multi-core system with 3GB of heap configured). No verbose-gc arguments. Using -server flag.
I found this issue when running a load test where the JVM is doing Minor GCs two times per second and a fullGC every 45 seconds. I've seen it to with systems under less load and with smaller or larger heaps. Just it maybe difficult to determine because the leak is small relative to the traffic and the rest of the objects in the heap.
The strings are very small, I know one of the three is: " Allocation Failure " (the reason the GC ran) and I haven't figured out what the other two are. I suspect related to the GC info.
I found this using YourKit. All these strings do not have GC roots and thus should be garbage collected but they are not. I tried stopping the traffic and launch manually several FullGCs and then taking a dump and all the leaked Strings were still present.
I've also noticed that in Java 7 Update 4, a notification callback was added to the GC code. I'm wondering if maybe this is what is leaking... When I connect JConsole it installs the call back and thus starts leaking.... Just a shot in the dark.
I believe this issue didn't exist in Java 6 update 23.
FYI, here is someone else that had the same problem:
http://stackoverflow.com/questions/13483796/memory-leak-in-a-java-web-application
THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Did not try
THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Launch a heavy load application. Connect JMX-Console to it. Do Jmaps to see the number of Strings (and char[]) growing with each GC cycle.
EXPECTED VERSUS ACTUAL BEHAVIOR :
JMX should not produce a leak in the JVM.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Don't use JMX-Console in production or in load tests.
Java version " 1.7.0_06 "
Java(TM) SE Runtime Environment (build 1.7.0_06-b24)
Java HotSpot(TM) 64-Bit Server VM (build 23.2-b09, mixed mode)
I have the same problem on 1.7.0_15 and 1.7.0_5.
FULL OS VERSION :
CentOS 5.6 2.6.18-238.el5 x86_64
A DESCRIPTION OF THE PROBLEM :
If I attach JMX-Console to my application the JVM will start to leak strings. About 3 strings per GC cycle I've estimated. If I disconnect JConsole, the VM will continue to leak strings. If I start a fresh test and never connect JConsole it never leaks, but once you connect it once it leaks for the life of the process. I'll a process restart solves the problem.
Currently using Concurrent Mark & Sweep GC (default when on a multi-core system with 3GB of heap configured). No verbose-gc arguments. Using -server flag.
I found this issue when running a load test where the JVM is doing Minor GCs two times per second and a fullGC every 45 seconds. I've seen it to with systems under less load and with smaller or larger heaps. Just it maybe difficult to determine because the leak is small relative to the traffic and the rest of the objects in the heap.
The strings are very small, I know one of the three is: " Allocation Failure " (the reason the GC ran) and I haven't figured out what the other two are. I suspect related to the GC info.
I found this using YourKit. All these strings do not have GC roots and thus should be garbage collected but they are not. I tried stopping the traffic and launch manually several FullGCs and then taking a dump and all the leaked Strings were still present.
I've also noticed that in Java 7 Update 4, a notification callback was added to the GC code. I'm wondering if maybe this is what is leaking... When I connect JConsole it installs the call back and thus starts leaking.... Just a shot in the dark.
I believe this issue didn't exist in Java 6 update 23.
FYI, here is someone else that had the same problem:
http://stackoverflow.com/questions/13483796/memory-leak-in-a-java-web-application
THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Did not try
THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Launch a heavy load application. Connect JMX-Console to it. Do Jmaps to see the number of Strings (and char[]) growing with each GC cycle.
EXPECTED VERSUS ACTUAL BEHAVIOR :
JMX should not produce a leak in the JVM.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Don't use JMX-Console in production or in load tests.