Add a comment

 

Re: JVM Lies: The OutOfMemory Myth

The OOM you refer to above is not actually strictly a proper VM out of memory. You are right, you made it worse by increasing memory pressure (possibly because you forced the entire process image up towards some memory barrier e.g. the classic 4GB barrier (actually even then all manner of other factors come into play here so whilst the naive idea is that 32bits == 4gb of accessible memory, that might not be the case, you may find that the total accessible memory is lower), but where it really comes from is the JIT. When the jit does a compile it needs to grab a chunk of memory for itself (known confusingly as swap space). Unfortunately in rare cases (typically when native libs screw with the JIT's life) you run out this "swap" space. What the JVM then does is a little undefined, (well I am sure the JIT engineers will argue with me, but I have seen this as the last thing in logs before some java app goes into Hellon Keller mode) - but largly this results in you getting "CompilerThread0" java.lang.OutOfMemoryError: requested Exception in thread "main" java.lang.OutOfMemoryError: requested 32756 bytes for ChunkPool::allocate. Out of swap space? The clues for this one are the words CompilerThread, swap space and chunk BTW its not a classic jvm OutOfMemory, hell its not even an exception, you can't trap it, it does not exist as any subclass of throwable , the gory details .. see http://12.101.252.19/hotspot/xref/src/share/vm/utilities/vmError.cpp (grep for swap space, hint what you see is a _string_ log message). I feel slightly sorry for you solving this one with a JIT OOM rather than a JVM oom, I was myself left with a feeling of being slightly cheated when I discovered that "out of swap space?" is a stdout message :S Btw if you need a huge heap, but still force native code / JIT to explode, you can attempt to reduce the stack size, which might by you precious extra bytes (but watch for StackOverFlowError :P) ... For the post stating native leaks, yes if the native code is leaking in the C side the process image will be large, but the JVM heap small, however another more fun native leak is code holding JNI Global references (these damn things pin objects so that the GC cannot touch them until the native code releases them). - This is gaurenteed fun as it looks like the javacode itself is the source of your leakage. (There are even more incidious ways to leak involving NIO, but I leave that topic for another day :P) As for the above post concerning temporary swap, thats for a different issue, related to process creation on the OS (and hence giving a different error (IOException)), however adding more swap does not fix a JIT explosion (even if the error message hints at this, it is referring to something different), I would recommend (many people would recommend) that the JVM never, ever lands on swap (unless you like your GC pauses to be very long), likewise sizing a heap beyond physical ram is simply asking for trouble. I have debugged more of these than is probably healthy :S As a plug on the tooling front, the newer jstat, jconsole, visualgc tools are great for this; as well is YourKit (which is possibly the nicest jvm profiler I have seen to date), they will basically tell you exactly where the fault is in no time at all.

Re: JVM Lies: The OutOfMemory Myth


Title
Body
HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).