Memory leaks of Garbage Collector objects

1
votes

I have a significant memory leak in my application. I have run jmap and it says that there are currently the following objects that should not be there (and are the major source of leak):

java.lang.management.MemoryUsage - 3938500 instances, 189048000 bytes
[Ljava.lang.management.MemoryUsage - 787700 instances, 31508000 bytes
com.sun.management.GCInfo - 293850 instances, 22055600 bytes
sun.management.GCInfoCompositeData - 393850 instances, 12603200 bytes

I do not directly use these objects. They are however used by Garbage Collector. I use:

Java version: 1.7.0-b147
VM version: Java Hotspot(TM) 64-bit Server VM (build 21.0-b17, mixed mode)
The application is run in Jetty version 7.3.1

I use currently Concurrent low pause garbage collector. However I had the same problem even when running the Throughput collector.

Do you have any idea why do these objects stay in the memory? What would you suggest to do?

UPDATE: The memory leak still occurs with Java 1.7 update 1 (1.7.0_01-b08, Java Hotspot(TM) 64-bit Server VM (build 21.1-b02, mixed mode) )

UPDATE 2: The memory leak is caused by JConsole. There are no instances of classes mentioned above before JConosole is started. Once I connect to the application with JConsole, the objects start to appear in the memory and they remain there forever. After I shutdown JConsole, objects are still in memory and the amount of them is growing until the application is shutdown.

4
javamemory-leaksgarbage-collection
There is a bug in loop optimization in the hot spot compiler. This could be the cause of there problem. Upgrade to 1.7.1 – Brett Walker
The GC doesn't uses these classes. However components monitoring the GC uses these classes to get information about GCs. – Peter Lawrey
I would guess that these are an artifact of having GC tracing turned on. – Hot Licks
Did you turn on some sort of profiling or tracing to track down the memory leak? I once had a classlaoder leak that was caused by using a hprof agent. Took quite a while to find that out, and it obscured the original problem which would only pop up occassionally. – G_H
I was using JConsole which is besides the other functions also monitoring memory. It could be the reason why these objects are in memory but even now when the JConsole is off, the amount of above mentioned objects in the memory is still growing. – Palo

4 Answers

4
votes

I have not really used jmap but I have handled memory leaks in our application.

Does your application go Out of Memory? I would suggest dumping before the application closes, add the following to your vm args

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp

When your application goes oom, it will create an hprof file under tmp that you can use to debug the issue.

If it doesn't go OOM, try allocate a lower memory so that you can force an OOM.

I used eclipse MAT to analyze this files. It is pretty good because it will immediately tell you suspects of the leak.

1
votes

I think you need to provide more details as to what the app is for and what it's doing. Are you just using jConsole for tracking this problem down?

I use Visual VM for tracking down these types of issues. See this link on how to use it for a memory leak and this one for the Visual VM main page.

0
votes

I have the same problem. I did investigation 2 months ago, and the problem is in JAVA 7_0 virtual machine. In my scenario java.lang.management.MemoryUsage object is hanging and daily growing hundreds of MB. All the other object you see hanging are referenced by java.lang.management.MemoryUsage object. The problem is, that this MemoryUsage object is hanging only in java 7_0 and higher version, because this MemoryUsage class has been added into JAVA 7 and was never in previous java. And most important is, that this MemoryUsage class is hanging in memory only after I use JConsole to connect to the server. After JConsole connects first time, it creates some MemoryUsage tracking mechanism, which starts to create MemoryUsage objects. Those objects are used then to draw the nice graphs in JConsole. This is all ok. BUT, the problem is, that JAVA 7 is buggy, and never frees the memory. The MemoryUsage objects are hanging forever on the heap. Doesn't matter that you close JConsole, it will continue to grow afterwards. The first time you use JConsole to connect to JAVA 7_0 process, you create the problem and there is no solution. Just don't use Jconsole, or any other memory monitoring tool, or don't use Java 7. In my scenario, I am doomed, because I have to use Jconsole all the time, and JAVA 6 is no option for me, because there is another bug, which makes memory leaks thanks to Locking objects. I reported this bug to ORACLE, but I have no idea, if they got it, know about it, and are solving it. I am just waiting for newer version of java so I can test it and stop restarting my server every few days.

0
votes

I reported an issue to Oracle a couple of years ago where in JDK 7, a memory leak would start the moment you connect JConsole. The leak would persist forever; even if you disconnect JConsole.

What was leaking? Objects relating to why the garbage collector ran. Mostly strings in fact (Like "Allocation Failure"). I only found the issue because I used YourKit and in YourKit you can analyse the objects that are tagged as garbage collectable. Basically the objects weren't being referenced by anything in my application but they weren't be collected by the garbage collector either.

Most heap dump tools remove garbage collectable objects from the analysis immediately. So YourKit was critical in pinpointing that the bug was really in the JVM.

Couldn't find my ticket but I found other ones: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7143760 http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7128632