Can't start up: not enough memory with -Xmx30G - java

I get the error message "Can't start up: not enough memory" when I run my code with "java -Xmx30G ExampleCode".
This error does not happen when I don't specify the java virtual machine size. Does anyone have a clue why I get that error message when I set the virtual machine size? If -Xmx is smaller than 1G then it runs, if not then I got the mentioned error message.
Thanks in advance for any help!
And yes, there is enough RAM :) (72G available).
BTW, JavaHome is /opt/jre1.6.0_20

The OS can impose a limit on how large a process can be. For example, in 32-bit windows, the limit is ~2GB, even if your machine has 4GB RAM. Check or OS settings, and be sure you are running a JVM where this would be allowed (i.e. if you're on a 64-bit system that supports this size process, be sure to run the 64-bit JVM)

You're probably running 32 bit java, see http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit

Make sure you're using the 64-bit JVM. I think the 32-bit memory limit is around 4GB of memory.

You need 64bit jvm to use more than 2/3Gb (depends on os version).

Related

Java Netbeans Heap Size

I have a Java project that needs a lot of memory to run. When I change the flags here:
It works fine, however I still need a bigger Heap size but whenever I choose a bigger size like 2g or something like that it always shows the following message:
Am I doing something wrong? And what can I do to correct this issue, I looked everywhere but can't seem to find a solution and I really need this for an assignment that is to be due sooner than I hoped...
EDIT: I should add that my computer has 8GB ram so that shouldn't be the issue and I'm working on Windows 10 if that matters.
EDIT1: When I click on help->about I get this window:
How can I conclude from here if my jvm is 32 or 64 bit?
How can I conclude from here if my jvm is 32 or 64 bit?
You are using a 32bit JVM.
A 64bit JVM includes that information in the version string, e.g.:
1.8.0_92; Java HotSpot(TM) 64-Bit Server VM 25.92-b14
A 32bit process is restricted to 2GB of memory and with Java you usually can't usually use more then about 1.2GB. I think this depends on the Windows version and configuration.
So just remove the 32bit JDK and install the 64bit one, then you can use all the 8GB that your computer has.

Java JVM Heap Size

I have an application that on launch requests a specific amount of RAM using the following command.
java -Xms512m -Xmx985m -jar someJarfile.jar
This command fails to run on my computer with 8.0GB of RAM because it can not create an object heap of the specified size. If I lower the max range to something below 700MB it works fine.
What is even stranger is that even doing a simple java -Xmx768m -version fails when the -Xmx flag value exceeds 700m. I am trying to run it with Java 1.7Uu67 32-bit(that is what the jar was built with) and even newer versions of Java 1.7 and event Java 1.8. I would understand if the max heap was higher and I was using 32bit, but it is not above the ~1.4GB cap of 32-bit java
Is there a configuration parameter that I am missing somewhere that would be causing this, some sort of software that may be interfering? It does not make sense to me as to why I can not allocate 700MB of RAM on a machine with 8.0GB of RAM. I
I should also note that there are no other processes running that are taking up all of my RAM. It is a fresh install of Windows 7.
While 700 MB is pretty low, it is not surprising.
The 32-bit Windows XP emulator in Windows works the same way as Windows XP with all it's limitations. It means you lose 2 GB or a potential 4 GB to the OS. This means programs already running use up virtual memory space. Also if your program uses shared libraries or off heap storage like direct memory and memory mapped files this will means you lose virtual memory for the heap. Effectively you are limited to 1.4 GB of virtual memory for your applications no matter how much memory you actually have.
The simple way around this it to use the 64-bit JVM which runs in your 64-bit OS and is also limited but instead to 192 TB of virtual memory on Windows.
You should try using a 64 bit Java Runtime. It is probably the case that there is no 985 MB large one-piece memory chunk free within the 32-bit address space of your computer (the 32 bit address space 4GB). When you use a 64 bit Java Runtime, Java can allocate the memory within the 64 bit address space, in which the free memory is much more likely to be available.
It doesn't matter that your JAR file was built using a 32 bit version.
The answer to your question may lie in the fact that Windows tries and fails to find a contiguous block of memory that is large enough: see http://javarevisited.blogspot.nl/2013/04/what-is-maximum-heap-size-for-32-bit-64-JVM-Java-memory.html. (Though this suggests that other processes are hogging memory, which seems to be contradicted by your last remark.)

32-bit JVM on 64-bit Windows crashes on launch with -Xmx1300m and plenty of free memory

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.

how to increase java memory (algorithms runs on ubuntu but not on mac; same machine configuration)

Recently I've been getting the notorious error message: OutOfMemoryError. I've a 64Bit Mac with 16GB Ram and 2X2.6 GH quad core. Getting this error message simply doesn't make sense to me because the same algoritm that I'm running (that causes this error message) is running smoothly on another machine (ubuntu 16GB Ram).
System.out.println(java.lang.Runtime.getRuntime().maxMemory());
When I run the above code on my mac I get: 129,957,888 (without the comma of course :-))
And when running this code on the ubuntu machine I get: 1,856,700,416
Can anyone tell me how I can increase my max memory in order to run my algorithm? Thanks!
I tried to set on my eclipse: default VM arguments -Xms512m -Xmx4g, but nothing changed.
-Xmx and -Xms are the correct arguments to the java command to change heap size, but Eclipse has to be configured differently.
You're going to have to elaborate. Are you running a test in Eclipse, or outside of Eclipse? Just passing the "-Xmx" parameter to Eclipse won't do what you want, even if you do it in the correct way to actually change the max mem value for Eclipse (that requires prefixing it with "-vmargs"). If you want to change the max mem value for the forked JVM that's running your algorithm, you have to change the parameters in the run configuration.
It looks like matt b has this one covered. I just wanted to mention that you might not want to set the max heap size as high as 4GB unless your program will really need that much. From what I understand the JVM allocates all of that memory for itself when it starts, and then uses it to run code as needed. Making it allocate that much memory might cause performance problems with other applications you're running. Instead, try stepping it up in increments of 128MB, or more if your code takes a long time to fail. Alternatively, maybe you can use a memory profiler to see how much space you actually use? I have no idea if such a thing exists.
This is probably not a problem on your setup, but for mere mortals like me, blithely allocating that much memory could be problematic.

IBM JRE 1.5 will not startup with the requested 1.5G memory

IBM JRE 5.0 on Windows, when given -Xmx1536m on a laptop with 2GB memory, refuses to start up: error message below. With -Xmx1000m it does start.
Also, it starts fine with -Xmx1536m on other servers and even laptops, so I think that there is something more than just inadequate memory.
Also, when started from within Eclipse (albeit, using the JRE in the IBM 5 JDK in this case) with the same memory parameter, it runs fine.
Any idea what is going on here?
JVMJ9VM015W Initialization error for library j9gc23(2): Failed to instantiate heap. 1536M requested
Could not create the Java virtual machine
Edit:
Does anyone know about the "3GB switch" and if it is relevant here (beyond the obvious fact that approximately that this is a memory limitations problem). How can I tell if it is enabled and what is the most straightforward way to turnit on?
According to IBM DeveloperWorks:
Cause
The system does not have the necessary resources to satisfy the
maximum default heap value required to
run the JVM.
To resolve, here is what it says
Resolving the problem
If you receive
this error message when starting the
JVM, free
memory by stopping other applications
that might be consuming system
resources.
Your JVM doesn't have enough memory resources to create maximum amount of heap space of 1536 MB. Just make sure that you have enough memory to accommodate it.
Also, I believe that in Windows, the maximum heap space is 1000MB? I'm not sure if that's solid, but in Linux/AIX, any Xmx more than 1GB works fine.
The JVM requires that it be able to allocate its memory as a single contiguous block. If you are on a 32-bit system, the maximum available is about 1280M more or less. To get more you must run a 64-bit JVM on a 64-bit OS.
You may be able to get a little more by starting the JVM immediately after rebooting.
As to starting OK on other systems, are those 32 or 64-bit?
Pretty much the maximum you are guaranteed to get on a Windows platform is 1450 MB. Sometimes Windows/Java.exe maps DLLS to addresses in the 1.5-2.0GB range. This doesn't change even if you use the /3GB trick (or you have an OS that supports it). You have to manually rebase the DLLs to get them higher towards the 2GB (or 3GB boundary). It's a real pain in the ass, and I've done it before, but the best I've ever been able to get with and without a combination of /3GB is 1.8G on 32bit Windows.
Best to be done with it and migrate to a 64-bit OS. They're prevalent now-a-days.
I have the same issue in IBM Engineering lifecycle installation:-
Problem:- JVMJ9VM015W Initialization error for library j9gc26(2): Failed to instantiate heap; Could not create the Java virtual machine.
Solution:- I just did it and solve my issue. If you don't have 16GB ram then please don't change the jazz server startup file. If you have 8GB ram then Only do not increase memory size in the server.:
**set JAVA_OPTS=%JAVA_OPTS% -Xmx4G**
**set JAVA_OPTS=%JAVA_OPTS% -Xms4G**
**set JAVA_OPTS=%JAVA_OPTS% -Xmn1G**

Categories