views:

115

answers:

5

I can set the max memory as 1000 and not more than that, if I set the memory more than that, it throws the following error.

Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine.

My question is, why jvm looks for the max memory at startup?

Thanks in advance.

A: 

why jvm looks for the max memory at startup.

It wants to make sure that it can eventually allocate the maximum amount which you said it could have.

Why do you need to set a higher maximum then your machine actually supports?

Answer: It would make JVM configuration easier, if you could just set it to basically unlimited, especially if you deployed to different machines. This was possible in earlier versions, but for the current Sun JVM, you have to figure out a "proper" value for every machine. Hopefully, there will be more clever/automatic memory settings in the future.

Thilo
Thanks Thilo. I understand wat u say.But can I get a source for it.
Mack
@Mack - the basic information is in the page I linked to; i.e. http://java.sun.com/javase/6/docs/technotes/tools/windows/java.html#options
Stephen C
+1  A: 

There are two command line parameters that directly control the size of the (normal) heap:

  • -Xmx<nnn> sets the maximum heap size
  • -Xms<nnn> sets the initial heap size

In both cases <nnn> is a number of bytes, with a k or m on the end to indicate kilobytes and megabytes respectively. The initial size gives the heap size allocated when the JVM starts, and the maximum size puts a limit on how big it can grow. (But the JVM also allocates memory for buffers, the "permgen" heap, stacks and other things ... in addition to the normal heap.)

It is not clear what options you are actually giving. (A value of 1000 doesn't make any sense. The -Xmx size has to be more than 2 megabytes and the -Xms size has to be more than 1 megabytes; see this page.)

There are advantages and disadvantages in making the initial heap size smaller than the maximum heap size; e.g. -Xms100m -Xmx1000m. But there is no point making the maximum heap size larger than the amount of virtual memory your machine can allocate to the JVM.

Stephen C
"But there is no point making the maximum heap size larger than the amount of virtual memory your machine can allocate to the JVM." If this is so, then why the above mentioned error occurs.
Mack
@Mack - presumably because *that is what you are actually doing!* If you told us what the options actually were, what OS you were running, and how much physical and virtual memory is available, we might be able to offer a better diagnosis.
Stephen C
A: 

As elaborated here for implementation reasons (basically it makes performance faster and that is their priority) the JVM requires contiguous memory addressing, so it has to establish that it has that at startup, otherwise it might to be available later.

The fact of the matter is that the JVM in many ways is a server-side oriented technology. That is where Java is popular so that is what gets the development attention.

Yishai
+1  A: 

The Sun JVM needs a contiguous area of memory for its heap. Using the tool vmmap from the Sysinternals suite you can examine the memory layout of the Java process exactly. To do that, write a simple Java program like this:

public class MemoryLayout {
    public static void main(String[] args) throws java.io.IOException {
        System.in.read();
    }
}

Compile that program and run it using the large heap settings

javac MemoryLayout.java
java -Xmx1000m -Xms1000m MemoryLayout

Then, start vmmap, select the java process and look for the yellow memory region whose size is larger than 1000000k. This is the JVM heap. Look further below, and you will eventually find a purple row indicating that there is a DLL file mapped. This DLL file prevents your JVM heap from growing bigger.

If you know what you are doing, you can then rebase that DLL, so it will be loaded at a different address. Microsoft provides a tool called rebase.exe as part of the Microsoft Platform SDK (I have version 5.2.3790.1830).

Roland Illig
A: 

If you use a 64-bit JVM on a 64-bit OS you won't have this problem. This is only a problem on 32-bit OSes.

Peter Lawrey