4

I do not understand how it is possible to get this exception while the total memory (Runtime.totalMemory()) used by the JVM is about half what can be allocated (Runtime.maxMemory()). Any idea ?

Total Memory : 1708MB as returned by Runtime.getRuntime().totalMemory() 
Max. Memory  : 3545MB as returned by Runtime.getRuntime().maxMemory() 

JRE : Java HotSpot(TM) 64-Bit Server VM  :  1.6.0_29   (Linux)
Marc Polizzi
  • 9,275
  • 3
  • 36
  • 61
  • I'm sorry, in a previous answer I induced you in a wrong way, I misread some information that is only relevant to RMI. – pcalcao Dec 29 '12 at 01:40

1 Answers1

1

As pcalcao mentioned, the JVM is telling you that it is spending too much time in garbage collection, and isn't doing enough real work, so it's just going to bail out.

This is kind of a safety valve to avoid the case that you haven't actually run out of memory, but are close enough that you really aren't making any forward progress. I won't belabor this point - this answer has a lot more detail, but I'll mention a couple things that might apply to your case:

This is more likely to happen if you SoftReferences to cache things - as the heap grows towards the maximum size, these references get cleared and possibly repeatedly regenerated (depending on if your key loop touches) them, resulting in some bad behavior where GC occurs constantly but always recovers enough memory to keep going because it is able to clear some soft references - even the JDK suffers from this as they use this kind of caching in their Locale classes.

You can disable this behaviour if you really want using -XX:-UseGCOverheadLimit. Still, the problem it indicates is real - you are spending less than 2% of your runtime doing real work.

Where are you printing out those memory values? Depending on how your program is structured, it may be generating a lot of garbage and using most of the heap in some inner loop, but at place you put your diagnositc output, the garbage as been reclaimed. -verbose:gc can give you a much better picture of actual GC behaviour.

Community
  • 1
  • 1
BeeOnRope
  • 60,350
  • 16
  • 207
  • 386
  • No SoftReference; no cache in this scenario; one single thread of processing allocating... I really need that RAM: there's nothing to deallocate. – Marc Polizzi Dec 29 '12 at 01:53
  • 1
    It is unusual that in a well-written application that you would get this error given that you'd have to be producing a huge number of objects with very little other processing to trigger this, or perhaps have oddly sized generations. -verbose:gc is going to be your friend here, perhaps in combination with jmap or jvisualvm. – BeeOnRope Dec 29 '12 at 02:01
  • More likely we got wrong log information; thanks for your input I've accepted the response. You might want to know that the Max. Memory can be larger than available in the OS (the JVM does not check). – Marc Polizzi Jan 03 '13 at 03:38