I am trying to run some .jar file but I am getting below error. The system has 20 gb of ram and my Xms and Xmx values are -Xms2048m -Xmx4096m
Are these values are too big or there is another thing causing this error?
java.lang.OutOfMemoryError: Java heap space
EDIT:
java -jar -Xms2048m -Xmx4096m /Filereadertest.jar
I am using java 1.7.51
Java HotSpot(TM) 64-Bit Server VM
Are these values are too big or there is another thing causing this error?
The default for the server JVM is 1/4 of main memory or 5 GB, so you are actually decreasing the maximum by setting this.
You could set it to 80% of main memory such as -Xmx16G
Along with JRE version and architecture, heap space per process also depends upon the operating system in use.
For example, Windows 32-bit allows maximum 2 GB memory per process, which also includes size for stacks, libraries and other stuff. So in practice, we generally get 1.25 GB memory.
Have a look at:
Oracle's Guidelines for Heap Space Sizing
I have an app that uses the following jvm options:
-Xmx512m -Xms256m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
-XX:MaxGCPauseMillis=2 -XX:MaxDirectMemorySize=1G
I run it on Windows 7 x64 with 8gb RAM. And when the task manager says that there's 60% of RAM is in use, it becomes impossible to run my program, Java says "Out of memory". Even though in theory I still have almost 3gb of free RAM left. Below are screenshots of profiling my project in NetBeans (until it suddenly crashes on a random spot). What could cause these problems? Is my program really so expensive?
(source: SSmaker.ru)
(source: SSmaker.ru)
You should greedy-allocate your minimum required overhead. That is,
use something like -Xms1g -XMx1g, so when your app actually starts running,
it has already reserved its maximal heap usage.
I'm struggling with Java heap space settings. The default Java on Windows is the 32-bit client regardless of OS version (that's what Oracle recommends to all users). It appears to set max heap size to 256 MB by default, and that is too little for me.
I use a custom launcher to start the application. I would like it to use more memory on computers with plenty RAM, and default to -Xmx512m on those with less RAM. As far as I'm aware, the only way is the static -Xmx setting (that has to be set on launch).
I have a user who has 8 GB RAM, 64-bit Windows and 32-bit Java 7. Maximum memory visible to the JVM is 4G (as returned by querying OperatingSystemMXBean). I understand why, no issue.
For some reason my application is unable to start for this user with -Xmx1300m, even though he has 2.3G free memory. He closed some applications (having 5G free memory), and still it would not launch. The error reported to me was:
error occured during init of vm
could not reserve enough space for object heap
What's going on? Could it be that the 32-bit JVM is only able to address the "first" 4G of memory and has to have a 1300M block available within those first 4 gigabytes?
How can I solve this problem, except for asking everyone to install 64-bit Java (what is unlikely to be acceptable)?
EDIT: In case it matters, it is a fat Swing client, not an applet.
It is not a question of memory but a question of address space.
On those 4 GB (2^32) theoretically addressable by a 32bit process, one must take into account the fact that the OS kernel needs a part of that address space (which obviously the process cannot touch).
And when you use Java, the address space of the java process itself is split further, between the heap, the permgen, native resources, the JVM itself etc.
You are using a 64bit OS. Run a 64bit JVM. Your bytecode (ie, all your jars) will run all the same. There is just no reason to be using a 32bit JVM!
Why won't it work?
As others have mentioned, this particular user's computer most likely does not have a large enough contiguous block of free memory for the JVM in a 32-bit address space. The maximum 32-bit heap space is system-dependent (note that both the OS and the exact JVM version make a difference) but is usually around 1100-1600 MB on Windows. For example, on my 64-bit Windows 7 system, these are my maximum -Xmx sizes for the specific 32-bit JVM versions I have installed:
Java 7: between 1100m and 1200m
Java 6: between 1400m and 1500m
Java 5: between 1500m and 1600m
The remaining memory allocated to the process is used by the OS (or emulator, in the case of a 32-bit process on a 64-bit host), the JVM itself, and other structures used by the JVM.
Recommended solution: bundle a 64-bit JVM with your application
If you cannot get the client to install a 64-bit JVM, bundle one with your application. The 64-bit address space will have a contiguous block of memory larger than 1300 MB free, even if there is not necessarily a large enough contiguous block of physical memory available.
If your software is a standalone application, it's a piece of cake to bundle the JVM. If the launcher is an applet, you might have to have your applet check for the 64-bit JVM in a known location (and download it if necessary) before launching your application.
Don't forget about dependencies
If your application uses 32-bit native libraries, make sure you can also get 64-bit versions of those native libraries.
What if you can't bundle a JVM or have 32-bit native dependencies?
There's really no reason why you shouldn't be able to bundle a JVM with your application, but you might have some 32-bit native dependencies that haven't been ported to 64-bit--in which case, it won't matter whether you bundle a JVM because you're still stuck with 32-bit. In that case, you can make your launcher perform a binary search to determine the maximum heap size by repeatedly executing java -Xmx####m -version and parsing the output (where #### is the Xmx value, of course). Once you've found the maximum Xmx, you can launch your program with that value. (Note: a slightly safer option would be to simply try to run your program and check for the heap space error, decreasing Xmx after each failed attempt to launch your program.)
You'll need to use a smaller Xmx value if you get an error message like one of the following:
Java 7:
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Java 6:
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
Java 5:
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
But if you get something like the following, you know you've either found the maximum or you can try a larger Xmx value:
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) Client VM (build 23.21-b01, mixed mode)
I agree with the previous answers. Just a couple of additional comments. Yes 32-bits can theoretically access 4GB, however in Windows the top half of this reserved for the operating system and the bottom half is for all applications. Since Windows considers Java a "user" program, not part of the OS, the best you could ever do is 2GB. And in practice it's a lot less than that. 1.2GB sounds about right.
However, when running in 32-bit mode, I would actually recommend dropping down to 1024M. If you absolutely max out the heap space, you may run into a more serious problem where you run out of "native memory". And if you have never experienced this before it's a real treat - because instead of getting a nice Java stack trace, the whole JVM immediately crashes.
And I agree with everyone else that you need to bite the bullet and enhance your application to support the 64-bit JVM. In my case we have a service wrapper so we needed to redistribute both JVMs and then a 32-bit service wrapper and a 64-bit service wrapper. The user could then register either the 32-bit or 64-bit version as needed.
Windows XP is limited to 1.2 - 1.4 GB of continuous memory. Even if you have a 64-bit JVM, the 32-bit emulation works the same as it does for Windows XP for compatibility i.e. the also has the same limitations.
If you want to use more memory, run the 64-bit JVM. Unless you have 32-bit DLLs, there is littel reason not to.
The application I work on requires as much memory as I can give it. through trial and error I have found that under Windows the most I can reliably assign to a 32-bit JVM is about 1200 MB. It varies slightly but I've never known it drop below this. Under Linux running OpenJVM I can sometimes assign 1300MB. There are many reasons for this limit but from what I've read one of the main issues stopping the JVM acquiring a larger heap than this is the requirement that the heap be one contiguous block of memory.
As you are on a 64bit machine, running a 64bit operating system I'd strongly recommend just switching to a 64bit JVM. You can then assign essentially unlimited amounts of memory. My experimentation however indicates that over about 10GB of memory it's a serious case of diminishing returns as the JVM doesn't seem to use it very well and performance suffers. I believe Java 8 will have better management of large amounts of memory.
I have got a problem. My program is really big and java is throwing OutOfMemoryException.
In .bat file, I have got the following:
java -server -Dfile.encoding=UTF-8 -Xmx1500m -Xbootclasspath/p:../libs/l2ft.jar -cp config/xml;../libs/*; l2ft.gameserver.GameServer
Java is using 6 GB of my RAM, next 6 GB is not used.
I typed System.getProperty("sun.arch.data.model"); and it says that I am using 64-bit JVM.
You have set the maximum heap size to 1500m and while the JVM can use a little more than that ~200 MB, that's all you limited the process to.
Try instead to limit your progress to around 5 GB. (You want to leave some memory for overhead and the OS)
-mx5g
Make the options before Xbootclasspath this:
java -XX:MaxPermSize=512m -server -Dfile.encoding=UTF-8 -Xmx8g -XX:+UseCompressedOops
This will make it use more memory and will also make sure it uses as little memory as possible to address the objects in a 64bits machine.
The -XX:MaxPermSize=512m makes the perm gem space larger (which you will probably need as you're using a lot of heap memory) and the -XX:+UseCompressedOops will make it use 32bits addressing for objects, instead of 64bits, as a 8gb heap can be correctly addressed with 32bits, so it makes you use less memory for allocating objects.
I've got a problem on my Solaris servers. When I launch a Sun Java process with restricted memory it takes more than twice the ressources.
For example, I have 64 Go of memory on my servers. 1 is on Linux, the others are on Solaris. I ran the same softwares on all servers (only java).
When servers starts they took between 400Mb and 1,2Gb of RAM. I launch my java process (generally between 4 and 16go per java process) and I can't run more than 32 Gb defined with Xmx and Xmx values. I got this kind of errors :
> /java -d64 -Xms8G -Xmx8G -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
As we can see here, I got a lot of reserved memory and it's made by java process :
> swap -s
total: 22303112k bytes allocated + 33845592k reserved = 56148704k used, 704828k available
As soon as I kill them 1 by 1, I recover my reserved space and could launch others. But in fact I can't use more than a half my memory.
Anybody know how to resolve this problem ?
Thanks
I believe the issue is Linux over committing memory allocation while Solaris is make sure what you allocate fit in virtual memory.
If you think that's a Linux advantage, you might reconsider it when Linux OOM killer randomly kill your mission critical application at it worst stage.
To fix the issue, just add more swap space to Solaris.