For what it's worth, I have no problem creating a JVM with those parameters on my Mac. Unfortunately I don't have a Windows box at the moment to test on. This might be a Windows XP limitation, or it might be a problem with the configuration of your own specific system. If you can test on any other systems, that might give helpful clues. Sorry I don't have more specific info.
Joined: Jan 10, 2007
On another computer - XP, 1GB allocation of 1024xms 1024xmx 256perm work. more than that - cannot allocate
so, this must be the computer configuration, but i dont have a clue about the problem becasue i see that 2.4GB of physical memory is avilable.
On Windows, before starting the Java app, open Task Manager, look on the Performance tab at the memory usage. From the Commit Charge you can tell the amount of memory available (Limit - Total). That memory must hold the JVM, all of its internal data structures, the permgen space and the heap. I would guess that if you do not have at least 1.2GB free you will not be able to allocate a 1GB heap because there is insufficient memory. You can then do one of two things: increase the page file size, or buy and install more RAM. I vote for the second because if you do not have enough RAM and you heap starts swapping you will run into major performance issues.
In the task manager i see that 2.4GB are avilable , but when i tried to run JVM with the parameters above - which required 1.25GB(1024M for heap and 256M for permenant) i get - you dont have enought resources. So i have memory avilable.
Wait a minute - was the error "not enough memory" or "not enough resources"? Please post the exact error text. A "not enough resources" error can happen if you run with the /3GB boot option and there is not enough memory for the OS to allocate things (such as the threads the Java app needs).
Joined: Jan 10, 2007
not enough resources - this was the error . can you explain?
Pat, this thread has nothing to do with needing more than 2GB of memory to run an application. Rather, I think it has to do with how Windows allocates memory, and thus what the root causes are for out-of-memory/resource errors.
Avihai, in 32-bit Windows, each application has a 4GB addressable memory space. By default, Windows reserves 2GB of that space for its use (which I believe is shared among all processes) and 2GB for the application's use (each app gets its own 2GB area). The /3GB boot option (which Vlado mentioned) changes this to 1GB for Windows and 3GB for each app.
The addressable memory allocated to Windows (2GB normally, 1GB if the /3GB boot option is used) is where Windows places all of the objects it uses to run the computer. Things like file info, thread info, objects for windows and other GUI artifacts. And like I said, I believe this space is shared among all apps. So every app that creates windows or threads or opens files reduces the amount on memory available for other applications. Eventually, there is little or no more room in this memory. Then when a Java app comes along it runs out of resources - likely causes being nor enough room for opening file handles to load large numbers of JAR files or nor enough room for allocating the myriad of threads that a typically Java-based application server will run (in my experience, it has always been the threads that cause the out of resources problem).
So what can you do? A few things. First, if you are booting with /3GB, don't. That will give the OS another 1GB to play with. If you are not booting with /3GB, then all you can do is determine which apps that you have running already are using up the system resources. For this you will need a tool like Process Explorer or Process Monitor from sysinternals. Those tools can tell you what resources are in use. Even Task Manager can be of use if you make several other columns on the Process tab available.
The other possibility is that you have set your app up to create a bunch of threads (like configuring Tomcat to create hundreds of HTTP threads), in which case you need to reduce the number of threads. [ August 05, 2008: Message edited by: Peter Johnson ]
Originally posted by Peter Johnson: Pat, this thread has nothing to do with needing more than 2GB of memory to run an application. Rather, I think it has to do with how Windows allocates memory, and thus what the root causes are for out-of-memory/resource errors.
OK, but I still maintain that applications that need gigs of memory needs a redesign.
There are some exceptions to the rule, giant FFTs of images from Mars, but in general, a gig of memory is a lot, and indicates something more fundamental is wrong with the design model. Even if you get it to work once, what happens when the input file is twice as big?
Pat, a 1GB heap (which is what Avihai is trying to allocate) is very typical when running application servers. For high-volume traffic I usually recommend starting with a 1.2GB heap, observing heap usage, and adjusting from there. I guess that is why the heap size did not phase me, I'm used to such sizes. When you have hundreds of concurrent users you end up generating a lot of objects that very quickly become garbage.
And besides the question was about why Windows would refuse to run a Java app even when it appears that there is enough available memory to allocate the specified heap. In other words, Avihai might have gotten the same error even with a 256MB (or smaller) heap.
As you may be aware, the maximum heap size on Window using JRockit - or for that matter any JVM we are aware of - has been limited to slightly below 2 GB. There have been two reasons for this. One is that the maximum process size on Windows has been limited to 2 GB, though this can be worked around by using the /3GB kernel switch. The second is that JVMs have required a contiguous memory space for the Java heap for efficiency reasons, which causes the maximum Java heap size to be limited by DLLs loaded into the process address space.
With JRockit 5.0 R26 this barrier is broken! By introducing support for split heaps, we have been able to significantly increase the Java heap size on Windows.
Windows 2003/XP using the /3GB switch (32-bit OS) 1.85 GB - JRockit 5.0 R25.2 (SP2) 2.85 GB - JRockit 5.0 R26 (SP3)"
I am running 64bit-jvm on a solaris10/spark platform. I have 16GB memory installed and I'm trying to run with parameters -Xms4000m and -Xmx8000m which should be ok for the installed memory. I'm getting Could not reserve enough space for object heap. Why? Is there an operating system configuration to alow this? Please help. 10x
Originally posted by Peter Johnson: For high-volume traffic I usually recommend starting with a 1.2GB heap, observing heap usage, and adjusting from there. I guess that is why the heap size did not phase me, I'm used to such sizes. When you have hundreds of concurrent users you end up generating a lot of objects that very quickly become garbage.
OK, this is moving OT to the OP's question.
But if you have hundreds of users, you usually run a real OS and have tons of RAM. I usually start with 12GB for real servers.
Window's handling of memory over 2GB is most wierd. I'm pretty sure that they never imagined anyone with 2GB of real RAM when they wrote NT3.1 back in the early 90s. When I beta tested NT3.1, 32MB of ram was insanely expensive and no one ran it.
First, please do not use abbreviations or text=messagingisms, such as "10x". They make your post harder to read and easier to misunderstand.
Based on the information you have provide, I am not sure why your JVM refused to allocate 4GB of heap. But here are some reasons why it might not:
1) You are really using a 32-bit JVM. I do not think that this is the case in Solaris, but people running 64-bit Linux or Windows on Intel or AMD can run 32-bit JVMs and thus still be subject to 32-bit memory restrictions.
2) There might be some setting in Solaris that restricts application memory usage. It has been years since I used Solaris, so maybe someone else could offer some suggestions here. Or you could just ask Sun - unless you are using Open Solaris, you paid for it and should get support.
3) Other apps might be using up memory and the available memory is less than 4GB.
4) The Sun JVM requires a contiguous process address space to allocate heap memory, and there might not be such a contiguous space. Note that this is process address space, which is logical, and not RAM or system memory address space, which is physical. I really do not think that this is the issue because with 64-bit addressing you should have plenty of logical address space available. (But this issue sometimes shows up with 32-bit JVMs if DLLs or shared objects loaded into the java process occupy unusual process memory locations.)