I'm not sure, but I *think* this is roughly how it works: Java doesn't just allocate the entire 'max heap size' when it starts up, instead it will allocate up to that amount if needed. Whenever java runs out of memory, it'll aggressively garbage collect first. You'll only get OOME when, after a full garbage collect, AND all the allowed memory (max heap size) has been allocated, there still isn't enough memory to create a new object.
The point of limiting max heap size, therefore, is to loosely force timely garbage collection. Giving an app a gigabyte also means it'll only do light garbage collection until its used up the entire gigabyte. There's also the issue of 'client' vs 'server' operating modes. Something like an applet (more relevant now with javafx and 6u10) really shouldn't take much more than 64MB. A server on the other hand, or something fairly big iron-style like an IDE, should take more. The point, possibly, in those circumstances, is that such applications tend to come with their own 'run app' shortcuts, and thus they can fiddle with the max heap internally. I'm 99% certain that both eclipse and netbeans give themselves a lot more than 64MB when they boot themselves up, for example. On a side-note: You also get OOMEs when you run out of stack (probably because some method is infinitely recursing), or when you run out of permgen memory, which would happen if you have too many classes in use (we're talking about many tens of thousands here). The text that goes with the OOME should tell you which type you're suffering from. Dynamically growing a stack size is perhaps more difficult, and you have 1 stack for each thread, instead of one heap for the entire JVM. Why OOMEs happen when you run out of permgen, instead of eating into the memory thats allocated for the heap is a bigger mystery. Perhaps the theory is that if you're running out of permgen now, there's a memory leak, and eating into the heap will merely result in an app that crashes a few hours later, becoming slow as molasses near the end because of near continuous full garbage collects. On Dec 31, 6:54 pm, "phil.swen...@gmail.com" <phil.swen...@gmail.com> wrote: > I've never understood why sun chose to have a "max heap size" setting > and default it to 64 megs. To figure out what your max heap size > should be you pretty much have to use trial and error. This makes > java inherently unstable. I can't count the # of times I've had > processes crash with an OutOfMemoryException because the heap size is > set either to the default 64 meg or too low. > > Why not do what every other runtime does and just allocate memory as > needed? And what exactly does the max heap size setting do anyway? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
