I have always shown people 'verbose' that is the way the heap is utilized when threads are acting on application. You have good tools to read verbose file generated by servers and plot it for better UI(I prefer IBM PMAT, pattern modelling and analysis tool).
A more intelligent set of people (esp in java) will not be all happy with this only. They would ask .."Which objects are there in heap?" ..Verbose has no answer. A Heap-dump would be having the answer.
The heap dump refers to a file (hprof or txt or phd file) that CAN be collected during the application-run. This is 'stop-the-world' and lengthy process and it will force JVM for compaction also, that means its not a thing to trigger every 10 minutes...although it can be! (For some servers, this has to be enabled before starting the server)
A heap dump obtained is a big file with cryptographic data present in it if opened in simple text editors. This can be read here but beyond my scope at this point. This has to be opened by specialized tool for reading heapDumps (like MDD4J, IBM-HeapDumpAnalyzer, Eclipse MAT --The best so far I found).
Once opened, you will find a lot of object names present at heap when the snapshot was taken. The UI will show number of each objects, size of each object. Thats ok. The best thing it has is the chain. Not all objects are created directly by the programmer. And once the class unloads, all its objects are cleared..great! No!.. Some objects due to bad coding remains forever.
Example: Cache Objects(implemented without soft referencing)
Other important object that stays in heap are due to big architectural dependencies, these are the objects like Connection, which gets created from a pool (usually) and is binded to various objects, something like Driver/Factory binding. so basically some object (say A) is created by B (directly) and registered by C (indirectly like binding). As B unloads, A remains in the heap as it has reference(C) living, that will kill automatic cleaning up feature of JVM.
There can be various other things available for keeping the object alive. The worst part is, in a heap you cant find the age of the object (I couldn't). Each big object (size wise and number wise) must be traversed to its dominator (parent object) to catch the leak....leak???... yes all the time B loads, it creates A' and A'' A''' A'''' and we have a lot of A's in heap (since C is something that HAS to be on heap and it holds ref. to A's) and one day our Java code will throw "OutOfMemoryException" ...yes thats like loop forever and create new Object in a loop!
God gifted quality of bad coding practices can lead to disaster.. this is not functional defect... This is quality defect!.. The code is perfect if code just means giving desired output. Yes it gives desired output but may fail to do so forever and absolutely not when concurrently accessed by million users forever.
To find these errors, we cant go through code and find defect..Not possible, We might find practice to be perfect but results are disastrous ...so ONLY one hope...."HEAP" dear coders.... please start reading heap!
I am doing these nowadays..Once I get more info... I ll share! thanks!