java.lang.OutOfMemory. Pinpoint & Mac. vers. Linux

[Rune]

I have a JAVA program with a number of threads, which when I run it on my
Mac (JAVA 1.3) runs flawlessly. It used to do so too on my Linux (JAVA 1.5)
but now it's starting to report a number java.lang.OutOfMemory: heap - even
though the Linux machine has the same amount of RAM as the Mac. Also I've
tried to catch the exception to pinpoint exactly where the exception is
thrown, but so far been unable. Is it not possible to catch
java.lang.OutOfMemory exceptions? And the exception doesn't print a stack
trace - merely OutOfMemory: heap size.



I've tried to change the -Xmx parameter, up to -Xmx512m, but without any
noticeable difference. But when I scale down the number of threads from 20
to 2 on the Linux the exceptions is apparently not thrown.



Why this big difference and how do I find out what exactly throws the
exception and eats all my memory?

 

[John C. Bollinger]

I have a JAVA program with a number of threads, which when I run it on my
Mac (JAVA 1.3) runs flawlessly. It used to do so too on my Linux (JAVA 1.5)
but now it's starting to report a number java.lang.OutOfMemory: heap - even
though the Linux machine has the same amount of RAM as the Mac. Also I've
tried to catch the exception to pinpoint exactly where the exception is
thrown, but so far been unable. Is it not possible to catch
java.lang.OutOfMemory exceptions? And the exception doesn't print a stack
trace - merely OutOfMemory: heap size.

That's OutOfMemoryError, not OutOfMemory. As the name indicates, it's
an Error, not an Exception. You can catch them, but it may be hard to
do anything afterward, as you may not be able to create any new objects
to work with. OutOfMemoryError does not print a stack trace because the
VM creates an instance at startup to use if it ever needs it, for if the
VM runs out of memory then it may not be able to create one at that time.

I've tried to change the -Xmx parameter, up to -Xmx512m, but without any
noticeable difference. But when I scale down the number of threads from 20
to 2 on the Linux the exceptions is apparently not thrown.



Why this big difference and how do I find out what exactly throws the
exception and eats all my memory?

I can't say why the difference, but it sounds fishy to me. Perhaps the
Mac's VM is grabbing additional memory (possibly virtual) as necessary?
Perhaps it's allowing even more heap by default than 512M? Run a
Java memory profiler. On both systems.

 

[Kevin McMurtrie]

I have a JAVA program with a number of threads, which when I run it on my
Mac (JAVA 1.3) runs flawlessly. It used to do so too on my Linux (JAVA 1.5)
but now it's starting to report a number java.lang.OutOfMemory: heap - even
though the Linux machine has the same amount of RAM as the Mac. Also I've
tried to catch the exception to pinpoint exactly where the exception is
thrown, but so far been unable. Is it not possible to catch
java.lang.OutOfMemory exceptions? And the exception doesn't print a stack
trace - merely OutOfMemory: heap size.



I've tried to change the -Xmx parameter, up to -Xmx512m, but without any
noticeable difference. But when I scale down the number of threads from 20
to 2 on the Linux the exceptions is apparently not thrown.



Why this big difference and how do I find out what exactly throws the
exception and eats all my memory?

The two systems will run threads slightly differently so you probably
have a synchronization bug. You could also be blocking the Finalizer
thread(s) with slow or incorrect finalize methods.