Phil Swenson posted "-Xmx is hurting Java" and spamlinked it on a mailing list this morning. His statement is that by limiting the available RAM to a JVM that's less than the available memory on the machine is a bad thing.

Here's his main point:

... going Out Of Memory on a system which does have enough memory is plain incorrect. Any program on a system can due to unforeseen circumstances might temporarily require more memory than its user thought it would. It could be that disk IO became slow or there were suddenly a traffic spike for a few minutes, etc. Operating Systems found a way around this a long time ago using virtual memory and disk swapping. Sure swapping causes your program to go slow but it doesn't outright crash it.

I have 24gb of ram on my machine (since ram is super cheap nowdays). I should never see an OutOfMemoryException. Yet time and again I see it pop up in Java programs, even when they were using a mere fraction of my 24 gigs of ram.

Well, he has a point because -Xmx can screw up his thing, chronon, which has a lot of memory requirements. But -Xmx is hurting him, not everyone else, and it makes sense in a virtual machine where garbage collection isn't free, and garbage collection not being free is what gets you away from having to manage all your memory yourself, and getting rid of it would create more problems than it would solve.

if he wants to use all the ram in his machine, why not use ByteBuffer.allocateDirect() and allocate it himself? That way he gets all the ram his application wants without making the rest of us vulnerable to whatever jerkwad overuses memory without realizing it.

And never mind how whingy the whole "talk to Mark Reinhold and get him to fix it" sounds.

I can think of several negative effects of giving the whole available memory to java:

* It makes memory leaks harder to detect

* It may have negative impact on GC performance

* It tempts to leave a wide open question about how much resources application _requires_ to work well.

Don't get me wrong, if resources provisioned for a process are insufficient _and_ there is a good reason to believe so, it is ok to give more resources.

But many times I've seen OOM causing blind restart with increased Xmx, with noone even trying to figure out the root cause.

I have 24gb of ram on my machine (since ram is super cheap nowdays). I should never see an OutOfMemoryException. Yet time and again I see it pop up in Java programs, even when they were using a mere fraction of my 24 gigs of ram.

Far better to let the heap grow uncontrollably until the machine starts swapping. Of course, you can always disable swap. Machines perform even better when they run out of swap. Mind, Linux never runs out of swap. If it gets close, it simply kills off the most offensive process it can find. 3 guesses as to which process that would be.

As I recall, Back In The Day, JRockit used to be able to run without a specified heap. But for whatever reason, using clouded judgement undoubtedly, they (apparently) require a heap setting today.

Now, one could argue that Java should just grow unbounded, like all of the other GCd systems. If you want to constrain it, there's mechanisms to do that at the OS level (how handy these are to use is a different question, and the techniques are not necessarily portable).

But that doesn't prevent the problem. The problem is running out of resources.

And running out of resources is a tuning problem. If you have a 24GB machine and you're not giving that all to your Java program, then, clearly, you don't expect that program to need all 24GB. And a surge is traffic that resorts in a massive allocation that sends an "unbounded" JVM in to swap territory, well, that's effectively as bad as getting OOM exception. You machine is toast. Because most systems don't give back memory once they start running, and if your JVM decided to sbrk 25G of your 24G heap, you're better off shooting the server and putting it out of its misery.

That said, OOM is the worlds worst exception. The best tested code fails horribly when it gets OOM. Never trust a system that has been hit with OOM, as you can have all sorts of failed state, like partially initialized objects, etc., even in the deepest part of the runtime library. OOM is when all those "this can never happen" exceptions start firing off. MOST of the system is fine, but SOME of it is not, and you have no control over what parts of the system are corrupted. Is that worse than a swapping system? Arguably it is. A swapping system usually doesn't corrupt data. A swapping system rarely recovers, whereas a surge can OOM a server and then when stuff rolls up, the OOM can "go away" as things are GCd, leaving a potential time bomb in your server.

What it boils down to is that even with things like GC and such, even as easy as memory management is today, we, as developers are STILL responsible for it. We're responsible for trying to guarantee that this never happens, otherwise innocent systems have to be destroyed. There's nothing worse than those photo's of doey eyed servers locked behind cages down at the Server Shelter, where damaged server images go, and nobody wants them, and their fate is dictated by the cold hearted reality of economics and productivity. Then some technician shows up, gives them a sad look of understanding, "It's not your fault", and then stabs the ENTER key on the kill(2) command.

So, man up. Fix your servers and keep them under control.

java.lang.OutOfMemoryError: PermGen space

First of all, I would like to point that Oracle JVM HotSpot may be tuned about OOM exception throwing. You can chance threshold to get it "earlier" or "later"

As JRockit has proven, there is alternative and different possible behaviours and implementations for memory allocation. But it may mean breaking C/C++ JVM implementation portability on platforms. Oracle targets Solaris, Linux and Windows. IBM targets AIX, Linux, Windows, i5/OS and z/OS. Not so easy to write a single code !

I have discovered that minimizing a Swing application on IBM JVM on Windows triggers a garbage collection and real heap compaction, the JVM memory just decreased.

For heap creation and extension "sbrk" is not the only option. Multiple anounymous "mmap" is far better. It allows JVM to trash a full mmaped zone in a single and cheap system call.

If GC was able to mark and sweep objects without have to scan the real object memory zones but by keeping reference counters in a dedicated memory zone, it would be possible to free a swapped page containing dead objects without getting the page back in RAM. Just tell the OS to unmap the zone. Consequence: swapping would not longer mean slowing down the GC.

With a specific communication between JVM and OS it is really possible to use as much as possible RAM without pain for the OS and other processes. The JVM may do more GC than increasing heap to avoid swapping, OS may ask for memory to the JVM and so triggers a GC with effective heap compaction...

Such communication exists between hypervisors and virtualized OS. Even in Java an application may "communicate" with GC thanks to SoftReference and ReferenceQueue - if only it was used in all cache implementations !

BEA has worked on a QNX based mini-system dedicated to run a single JRockit and WebLogic server (and of course JavaEE applications) directly as  vmware virtual machine: dynamic memory management with GC/OS/hypervisor communication, in addition to existing vmware features for QoS, CPU sharing, identical memory pages detection, swapping. Really great ideas but where is that project now ?

So I think more operating-system guys should work on JVM implementations.

The Java software is written not just for the servers with experienced admins who know about -Xmx and where to set it.

If you are writing some desktop app like Eclipse RCP one the high heap limit will be always your headache. You never can guess how your customer will use your software and how many memory will be available. That kind of applications is not much sensitive for effectiveness of GC but much more important do not bother users to looking for some config file and setting some magic values in there.

-Xmx is one of the singularily stupid things in Java. It reminds me of Mac OS 8 where we had to manually alocate RAM between running programs.

Java should be able to dynamically adjust heap size to allow it to grow _and_ shrink. And though it's possible to make Java heap shrinkable right now with the right combination of -X keys, it should be the standard behavior for desktop apps.

Java should be able to dynamically adjust heap size to allow it to grow _and_ shrink. And though it's possible to make Java heap shrinkable right now with the right combination of -X keys, it should be the standard behavior for desktop apps.

Exactly! There's absolutely no technical reason why a GC system should require the a runtime configuration to determine the amount of ram needed (which is guesswork in practice).

It's idiotic and must go away.

When I use Java with no -Xms/-Xmx parameters, it shrinks and grows as needed, and uses up to 2GB! (The "old" Java 1.6 on Mac OSX.)

Isn't that what you are asking for?

Why would you complain about the option (which is classified as -X i.e. not even a standard option!) to set the maximum size?

Peace,

Cameron Purdy | Oracle

Isn't that what you are asking for?

Why would you complain about the option (which is classified as -X i.e. not even a standard option!) to set the maximum size?

Without this option the heap size on Oracle/Sun JVM is limited to about 128Mb.

Isn't that what you are asking for?

Why would you complain about the option (which is classified as -X i.e. not even a standard option!) to set the maximum size?

Without this option the heap size on Oracle/Sun JVM is limited to about 128Mb.

Strange. On the Mac, it's 2GB. I know it used to be 64MB, but that was eons ago.

Peace,

Cameron Purdy | Oracle

Ok, lets say jvm has the smarts to analyse the physical ram of a system and decide to use as much memory as it thinks is available.  Then what if its wrong?  How does it know whether there are other important processes running on the OS at the time, and what their memory requirements are?  How can a SA limit the amoung of memory the jvm allocates to itself in order to leave room for other processes that may be on the system?

ulimit would be a solution for limiting ram available to a process.

If we are stuck with always specifying -Xmx even for desktop applications, then we need robust frameworks and programming techniques to effectively and productively work with such limitations. Currently this is hard unless you in effect implement your own memory management. There is not even a reliable way to say how much free memory you can work with due to nature of GC.

Java should be able to dynamically adjust heap size to allow it to grow _and_ shrink.

+1. Currently, if your software runs on different hardware for different use cases, you have to chose:

• take a big value (512M or more), even though you need far less normally. This migt starve the other processes on the machine and makes your software a bad citizen.
• take a small value, crashing on big use cases

    The article misses a fundamental point: the entire purpose of an application server is to manage resources.  Oh, like memory.  In many, many shops in the world, a given physical server is likely to host a mixed workload that may include multiple JVM's.  If you were to argue, perhaps, that there should be an option for unlimited heap growth, I'd agree.  But the  potential ramifications of unmanaged memory growth (from running out of native memory for threads to causing other key OS processes to fail) make this suggestion a poor idea on its face, and one that would cause many shops to experience unpredictable failures anywhere on a server under load -- one of the precise things that app servers are intended to avoid.

 ... make this suggestion a poor idea on its face, and one that would cause many shops to experience unpredictable failures anywhere on a server under load...

More unpredictable than JVM OutOfMemory? Moronic logic.

No it's not. When running multiple VMs on one physical machine with no limit to each VMs amount of memory (or CPU, or whatever resource), there is the possibility of one VM bringing down all the others when it is eating up all the available memory. In that case, limiting the amount of memory per VM can definitely make the situation less unpredictable, since only the offending VM will go down, instead of taking some or all the other VMs with it.

That said, whether you want to limit resources available to a process at VM level or at OS or other level is open for debate.

Moronic?  What a... civil, adult response.

As Shaw said, having one JVM become unstable is generally preferred to having an entire server become so.  For example, anyone remember how some OS's randomly kill processes when they run our of virtual memory?  Perhaps one likes the idea of a bad overload in one process causing another to throw errors because it can't start a thread?  Or being unable to start an FTP session.... you get the idea.

Back in the day, it made sense to have a total memory limit in Java because there was no consistency in how OS's managed this.  It's less necessary now, but I still think it makes sense to have this option.  I'd be in favor of a universal "unlimited heap" config setting, however.

In Azul's JVMs, we've been doing elastic memory for Java for a few years now, and have build up some experience in what works and what doesn't. Most administrators would interpret -Xmx as committed memory, within which predictable behavior is expected - it's what your Java app needs to run well according to your testing, and what you thiunk it needs in production. Where possible, most would prefer to not launch a JVM unless a known amount of physical memory can be provisioned or committed to it. Anyone whose experienced what happen to a JVM that swaps during garbage collection knows to avoid swapping like the plague.

However, allowing heap growth above (and shrinking back to) Xmx by using available *physical* memory has turned out to be extremely useful for both stability and efficiency, as getting Xmx "just right" is not an easy thing in the real world. If you set it too small, spikes in load or state will compromise stability (not to mention the effect of slow memory leaks if you have them). If you make it too large, dedicated memory is wasted.

To do elastic memory well though, you first need to solve some GC problems - e.g. if your longer pauses grow with memory size, growing memory becomes "undesirable", and in order to shrink memory back down you really want to GC to compact it. Once GC pauses and fragmentation become a non-issue (e.g. with our Zing JVM and the C4 collector it uses), Java elastic memory becomes a real thing too.

-- Gil Tene | Azul Systems

Gotta luv Azul

There are plenty of information about this topic in the net & some are definitely better than others.

Attic Conversion

@Richard Mayhew:

"Phil Swenson posted "-Xmx is hurting Java" and spamlinked it on a mailing list this morning."

I didn't write the blog post, I only referenced it. Here is the guy who wrote it:  http://posterous.com/people/4SsZesoOSCBz  Please at least try to be accurate with your accustations.

I agree with the post (mostly) though.  -Xmx makes java inherently unstable.  If an app happens to cross the magic heap threshold it is most likely left in a hosed state.  Is that really what anyone wants?

One of the most common customer complaints I've seen is "we got an OutOfMemory Exception, what should we do?" The answer is to crank up Xmx of course.  Every customer will have a differnent memory usage level, depending on their load/install/os/etc.

I would suggest either defaulting to an allocate as needed strategy or add another JVM argument to offer this opion.  Of course leave in -Xmx for people who need it.  .net seems to be able to handle an allocate as needed strategy.  Why can't Oracle?

Guys, just use Oracle JRockit (yeah, it's free!) and no more those neat OutofMemory exceptions.... 

--

Wanderson Santos

The assertion that "-Xmx is hurting Java" is so idiotic that it shouldn't be discussed. Really. I bet I can lower their memory requirements while maintaining an acceptable level of performance; however they prefer to complain (as usually) that someone else (or in this case something else) is to blame.