On 32-bit Windows Vista with 3 gig memory, I very often (or almost always) get this error if using XX:+AggressiveHeap option:
Error occurred during initialization of VM
Could not reserve enough space for object heap
Is there a solution?
How big is the heap that you are attempting to create? The limiting size is significantly less than 2GB.
>How big is the heap that you are attempting to create? The limiting size is >significantly less than 2GB
I am not specifying heap size -- just using -XX:+AggressiveHeap option
AggressiveHeap tries to size the heap as large as possible. However,
it's a very old option that isn't well maintained. It was most likely not
updated for Vista.
Fortunately, you can override the AggressiveHeap heap settings by
specifying -Xms -Xmx and -Xmn on the command line. You'll want to
set -Xms == -Xmx, as that's one of the the things AggressiveHeap does.
One final note - although you'll still see AggressiveHeap used in some
benchmark results (typically AppServer benchmark results), the JVM
team view AggressiveHeap as an anachronism and would like to see
it go away. Instead, we'd prefer for you to determine which of the individual
options that AggressiveHeap sets actually impact your app, and then set
those on the command line directly. You can check the Open JDK source
code to see what AggressiveHeap actually does (arguments.cpp).
This is usually a result of insufficient process virtual address space. However,
it could also be a result of a fragmented process virtual address space. In
either case, the JVM can't reserve the contiguous virtual address space for
the Java heap.
The typical solutions are:
- -Xss - where size is something smaller than you are currently
using. If you are using the default, then try -Xss256k or -Xss 128k. Note,
though, that the smaller you set this, the higher the risk that you'll take
a stack overflow error. Every thread is different when it comes to stack
space usage, so you need to size of the worst case thread in your app.
There's no easy way to monitor how deep you stacks get, so this is
mostly guesswork with some load testing added for good measure.
- Set -Xmx to a smaller value
- Set -XX:MaxPermSize to a smaller value.
For both of these, smaller heap and/or perm sizes could increase
gc frequency or result in OOM errors.
- Get a dump of the process address map and see if there's something
in particular that fragmenting the address space and preventing the
JVM from starting.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.