Re: Memory leak due to too many threads?
On Wed, 6 Aug 2008, bernd wrote:
Exception in thread "CompilerThread0" java.lang.OutOfMemoryError:
requested 32756 bytes for ChunkPool::allocate. Out of swap space?
This seems to be a known bug:
http://dschneller.blogspot.com/2007/04/exception-in-compilerthread0.html
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6487381
http://www.codingthearchitecture.com/2008/01/14/jvm_lies_the_outofmemory_myth.html
(ping Mark Space - i draw your attention in particular to the last of
those links!)
Try upgrading your JVM. Failing that, look for leaks in the native code -
what's happening is that native space is being gobbled up, and then the
JVM's compiler gets upset.
1. Is it just by chance that (and possibly due to the ?waiting? nature
of the sleep-Thread) that the interruption occurs during the sleep() or
does this point to a too high number of threads in my application which
lead to the memory leak?
It happens because HotSpot is running when all the app threads are asleep.
2. Up to now I did not explicitly stop() any thread in my application.
Is this strictly necessary or may I rely on the GC to not run into
trouble with too a high number of threads?
Should be fine.
Is it possible to destroy the Mqueue-object, which from my point of view
is the possible originator of the leak, after it is not used any more to
avoid the leak?
You can't explicitly destroy any java object. You can ensure that there
are no references to it, and let it be collected. But in this case, i
don't think that's where the leak is.
3. How do I find out the exact reason for the memory leak?
If there was a general answer to that, the world would be a much happier
place!
I am just speculating concerning the threads being the reason for the
problem. Is this possible by only using the JVM and appropriate command
line option?
No. And i think the leak is likely to be in your native message queue
code, not anything to do with threads. Are you mallocing a buffer and then
not freeing it when you do a receive?
4. Is it worth to play around with the ?Xmx option of the JVM?
One of those links suggests *decreasing* the size of the heap.
tom
--
There never was any carrier in the first place.