i have a very strange problem. I'm working on an OSGi application, based on Eclipse Equinox; it was developed using OSGi Log Service (Equinox implementation) and now I'm testing it with the Apache Felix OSGi Log Service implementation.
At API/code side, all works fine: the OSGi log service is standard, so i can swap from Equinox to Felix without problem.
However, I observed this strange behaviour: I started the application as console program, to see the log output on console, and i attached it the JVisualVM to analize the memory usage; the JVisualVM graph showed an used heap of 80 MBs.
After 13 hours, the average heap size reached the 220 MBs , so i decided to analize the heap dump, and i pressed the "Heap Dump" button: after this operation, the JVisualVM graph showed an used heap of 20(min)-35(max)MBs (?!?!), and this value was constant.
Can "Heap Dump" operation release almost 200 mbs? If yes, WHY?
I never saw this behaviour with the Equinox OSGi Log Service implementation, so i suspect that the Felix Log is involved in this problem...
thanks
Yes it can. I haven't studied the code but I am pretty sure it calls HotSpotDiagnosticMXBean.dumpHeap with the second argument set to true (it is the default if you call it form jconsole or the MBeans extension to JVisualVM). In my experience, doing so will trigger an explicit gc before it dumps the heap and that is probably the answer to the "Why?".
Why are you even bothered by GC? If the memory is properly released, there is no need to worry. But if you want to discover what causes heap to grow (even thou it's not a leak), look at this: How can I take a heap dump on Java 5 without garbage collecting first?.