Add More Maximum Memory For Java Mac OS X

STACK GUARD 000000011aa88000-000000011aa89000 4K ---rwx SMNUL stack guard for thread 27.

You have added -Xmx option to your startup scripts and sat back relaxed knowing that there is no way your Java process is going to eat up more memory than your fine-tuned option had permitted.

But in 99 of the cases it is completely normal behaviour by the JVM.

What you have specified via the -Xmx switches is limiting the memory consumed by your application heap.

In short, you can predict your application memory usage with the following formula.

In order for the garbage collector to know which objects are eligible for collection, it needs to keep track of the object graphs.

So this is one part of the memory lost to this internal bookkeeping.

G1 is especially known for its excessive appetite for additional memory, so be aware of this.

Again, to know which parts to optimize it needs to keep track of the execution of certain code parts.

If you happen to use off-heap memory, for example while using direct or mapped ByteBuffers yourself or via some clever 3rd party API then voila you are extending your heap to something you actually cannot control via JVM configuration.

But is there a way to predict how much memory is actually going to be needed Or at least understand where it disappears in order to optimize.

The JVM overhead can range from anything between just a few percentages to several hundred.

So you need to run your application with loads similar to production environment and measure it.

Subtract the heap and permgen sizes from the real consumption and you see the overhead posed.

Add More Maximum Memory For Java Mac OS X

We have found vmmap on Mac OS X and pmap on Linux to be a truly helpful tools in this case.

We have not used the vmmap port to Windows by ourselves, but it seems there is a tool for Windows fanboys as well.

I have launched my Jetty with the following startup parameters.

But now when I look at the Activity Monitor on my Mac OS X, I see something different.

Now digging under the hood how the process with the help of the vmmap output we start to understand where the memory is disappearing.

Stack 000000011aa8c000-000000011ab8b000 1020K rw-rwx SMZER thread 27.

Stack 000000011ab8f000-000000011ac8e000 1020K rw-rwx SMZER thread 28.

Stack 000000011ac92000-000000011ad91000 1020K rw-rwx SMZER thread 29.

Stack 000000011af0f000-000000011b00e000 1020K rw-rwx SMZER thread 30.