6

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

elDarioz
  • 61
  • 1
  • 2

2 Answers2

11

Can "Heap Dump" operation release almost 200 mbs? If yes, WHY?

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?".

Fredrik
  • 5,759
  • 2
  • 26
  • 32
  • 4
    Why? Because when you want to find memory leak, you don't want get those object which has no references, but was not yet garbage-collected. Therefor VisualVM triggers full GC before taking the heap dump. – Tomas Hurka Mar 24 '11 at 19:43
  • @Tomas Hurka Yes? Of course that is why you have that option (although there are really good uses of the other alternative as well). I interpreted the OP's "WHY?" more like "Why is it releasing the memory?" and the answer to that is "because VisualVM asks it to do so" before heapdumping. – Fredrik Mar 24 '11 at 19:52
  • I see. Can you tell me what are those really good uses of the other alternative? – Tomas Hurka Mar 24 '11 at 20:00
  • 3
    @Thomas Hurka Most of the times I use it is when I want to find out unintentional waste. Typically when using something like MAT to nail the reason for bad GC performance and such. – Fredrik Mar 24 '11 at 20:40
  • 3
    If you suspect that your program is allocating many temporary objects in an inner loop somewhere you might want to look at the heap prior to collection to see what they are. Mostly you want to let the GC do its job, but sometimes it helps performance to avoid allocating/gc in CPU-intensive code. – Christopher Barber Mar 18 '15 at 20:39
3

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?.

Community
  • 1
  • 1
Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
  • 1
    In the real world, especially in finance and other low latency areas, you really want to to minimize the work the GC has to do and analyze the heap and figure out possible waste. "Just let the GC do its job" is a good strategy for most java applications but not when a 25ms full stop can cost you what a good developer costs per year. – Fredrik Jun 08 '16 at 22:53