You want us to write a book for you? Visual VM is a tool, like a knife is a tool. Asking "How to analyze system, thread and classes in Visual VM?" is like saying "How do I use a knife to cut vegetables, meat and self defense?". The answer can be something glib like "Hold it in your hand, cut" or you could spend a lifetime becoming experts in using knives. The simplest answer to your question is :- Visual VM shows you the heap dump and allows you to profile CPU usage. Use that. That's a very glib answer. It might not help you. Explaining the ins and outs of VisualVM is too big for a message board. That's like writing a book
What are you trying to do? Fix a memory problem? Investigate a performance issue? If you have something specific, people can help you with it.
thankyou for replyed to my post and my ? is, In visualvm displayed memory values are different while compairing the usagememory in taskmanager....( and i have converted the values from bytes to kilobytes) & how we should findout memory leakage in visualvm
I would download EclipseMAT (its free and will run standalone), get a heap dump of your app when you think it may have leaked and run its memory leak report button ;-) , it still needs some interpretation but is probably a better starting point.
I use Visual VM for some tasks but for this analysis you could almost do with a book or a very long blog to so general a question.
manie kandan wrote:thankyou for replyed to my post and my ? is, In visualvm displayed memory values are different while compairing the usagememory in taskmanager....( and i have converted the values from bytes to kilobytes) & how we should findout memory leakage in visualvm
The way memory works in java that java has a heap which is built on top of memory that java gets from the OS. THe heap is used to store objects. When you create a new object, Java checks if there is space on the heap for that object. If there is not, it asks the OS for more memory. WHen you release the object, Java takes it out of the heap, but doesn't return the memory back to the OS Atleast not immediately. Next time you create an object, java sees that it has enough free space on the heap, and it simply reuses that space. This avoids Java from allocating and deallocating memory continiously. Allocation of memory is costly, and holding on to the memory results in higher performance
This will result in a situation where the the size of the heap is smaller than the memory that Java has allocated from the OS. This is completely normal and expected. Visual VM is telling you the size of the heap; ie the size of the objects that are created by the app. The Task manager is telling you the amount of memory that Java has allocated. Both numbers will never match, and the amount of memory allocated by the OS will always be greater. Java will also hold on to the memory allocated from the OS for a lot longer than you expect. This is all part of normal operation of the JVM. There's nothing to worry about
To get the number from Task manager you will need to sum not just the Heap Memory, but the Permanent generation space ,the number of thread times the space of each thread and the native memory mapped (such as JNI, using NIO, etc). This will give you a very more accurate number. =)
Hope it helped! Kind regards!
Post by:autobot
Space pants. Tiny ad:
a bit of art, as a gift, the permaculture playing cards