Man, this thread contains a lot of FUD about how GC works (or doesn't work).
First point, Java heap must be contiguous for the current GC implementations. Which means you have to specify -Xmx right at startup. At start, the JVM will reserve -Xmx amount of C heap for Java heap. Java heap is then expanded from reserved memory when Hotspot determines that it could benefit or needs more memory. Java heap will *never* grow bigger than the setting of -Xmx. If you don't specify -Xmx, the default is to set it to 1/4 of physical ram starting with a portion allocated (depending on which hotspot engine is invoked). The parallel collector is more ergonomic than the default CMS collector. This means that while CMS generally won't resize to be smaller, the parallel collector will adapt to pause time and throughput goals. I've got a gc log lying about some where that clearly demonstrates the spaces resizing based on load. Memory is generally never given back to the OS as it's a very very tricky thing to do. To give memory pack you need to guarantee 100% that you have no pointers to anything in the space you're about to give back or you risk a SEGV. In some cases, dealloc does nothing. C applications will take as much memory as the OS will give them. Since the JVM is a C application, it will take as much memory as the OS will give it. And it sometimes does take more memory than you'd expect. However, Java heap -Xmx setting is *always* honored. If your JVM is 10g with a 2g -Xmx heap setting it is the C heap that is consuming the other 8gigs. You've got an NIO or JNI or some thing else causing a native C heap leak. Should one let a JVM take as much heap as is possible? I think it's a pretty dangerous thing to do. If you let the JVM take *all* memory, what happens when it runs out. Current if the JVM runs out of memory (not native C heap but Java heap) there is still something the JVM can do to try to recover. Even is native heap is seemingly exhausted, there are guard pages put into the process that allow the JVM to try to do something reasonable. Current implementations (including Azul's) are all encumbered by these restrictions. Azul just happens to be a bit smarter at the moment in how they manage it. But even they are constrained as to what they can do by the underlying hardware/OS. In fact, they run in a hacked up OS that is specifically tuned for their JVM. Nothing wrong with this but.... I could go on. Regards, Kirk On Aug 13, 2011, at 1:25 PM, mgkimsal wrote: > Why, then, on my JVM web app, when I specify -Xmx2g, do I see a Java > process > eating up 10g on my system? -Xmx doesn't seem to honor anything I > give it - > it just uses up all the memory on my server. > > > > On Aug 12, 11:53 am, PhilDin <philb%[email protected]> wrote: >> I've always wondered about this, before I encountered OOM, I just >> assumed that the JVM would keep asking for memory until the underlying >> OS refused to give it any more. Then, when I found the -Xmx switch, I >> assumed that there was an option to specify "as much as you can get >> from the OS" but again, no. >> >> I imagine the people working on the JVM are a little smarter than the >> average bear so there's probably good, non-trivial reasons for >> requiring -Xmx but I don't know what they are. Can anyone give some >> pointers on this? Also, what does the .Net CLR do? Does it impose any >> constraints on memory allocation? Does it suffer from poorer garbage >> collection or allocation performance at the expense of its strategy? >> >> Thanks, >> Phil >> > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
