I am using below GC memory parameters :
export MEM_OPTS="-Xmx2900m -Xms2900m -XX:NewSize=786m -XX:MaxNewSize=786m -XX:+UseTLAB -XX:MaxPermSize=128m"
I am using 32 bit JVM.My server RAM is 10 GB.
From Oracle site, I got
Why can't I get a larger heap with the 32-bit JVM?
The maximum theoretical heap limit for the 32-bit JVM is 4G. Due to various additional constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, in practice the limit can be much lower. On most modern 32-bit Windows systems the maximum heap size will range from 1.4G to 1.6G. On 32-bit Solaris kernels the address space is limited to 2G. On 64-bit operating systems running the 32-bit VM, the max heap size can be higher, approaching 4G on many Solaris systems.
As of Java SE 6, the Windows /3GB boot.ini feature is not supported.
If your application requires a very large heap you should use a 64-bit VM on a version of the operating system that supports 64-bit applications. See Java SE Supported System Configurations for details.
Ok.Now lets assume my 32 bit server can take 3.2 GB.As i know :
-Xmx is the total heap memory
-XX:NewSize / -XX:MaxNewSize is the range of the size of the new generation inside that heap
the difference is the range of the size of the old generation
-XX:PermSize / -XX:MaxPermSize is the range of the size of the permanent generation, which is the non-heap memory
According to this, 3.2 GB should not include PermSize as this is a not a heap content.Right ?
Let me know if am wrong.
I can divide 3.2 GB in Xmx and NewSize . Right ?
The NewSize is a portion of the maximum heap size. It must be smaller.
I would use the 64-bit JVM if you have Java 6 as it will make your life simpler. ;) Unless you have to use 32-bit share libraries, there is little down side.
BTW -XX:+UseTLAB is the default.
Related
My Jenkins build is running out of memory because of JUnits. When I try to give it (the JUnits) more than 4GB it errors out. I am using Linux as my build machine.
Invalid maximum heap size: -Xmx4096m
I am just wondering, is there a upper limit to how much heap size JUnits can use?
"For a 32-bit process model, the maximum virtual address size of the process is typically 4 GB, though some operating systems limit this to 2 GB or 3 GB. The maximum heap size is typically -Xmx3800m (1600m) for 2 GB limits), though the actual limitation is application dependent. For 64-bit process models, the maximum is essentially unlimited."
Found a pretty good answer here:
Java maximum memory on Windows XP
Memory is allocated to JVM not JUnit or any other class.
and there is limit on 32-bit system to assign max of 4Gb but if you requires more memory then move to 64 bit machine as there is no limit of max memory allocation .
i would guess you are using a 32 bit jvm ..
check this post:
Maximum Java heap size of a 32-bit JVM on a 64-bit OS
It's not JUnit but JVM. 4GB heap is too much for 32-bit JVMs.
I am aware that JDK 7 is supposed to be a merger between hotspot and jrockit and that there will not be a jrockit 1.7. (Source: https://blogs.oracle.com/henrik/entry/java_7_questions_answers) I have a project that requires the non-contiguous heap feature of jrockit as well as some java 1.7 features, so since JDK 7 is a merger, does it support non-contiguous heap because I can't find an offical documentation which says so?
I assume that you are asking about non-contiguous heaps because you are suffering from memory fragmentation. A lot of the time your 32-bit address space is fragmented, but your 64-bit address space is not. Meaning, if your computer has sufficient memory, using a 64-bit JVM will allow you to find contiguous memory that a 32-bit JVM will not. I have personally used a 64-bit JVM to allocate heaps over 4GB when a 32-bit JVM failed to allocate a heap over 2GB.
Although it doesn't look like arbitrary non-contiguous heaps made it into JDK 7, you can try using the G1 garbage collector. According to http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html:
The heap is partitioned into a set of equal-sized heap regions, each a contiguous range of virtual memory.
Theoretically speaking, this allows you to play with a non-contiguous heap. The only limitation is that the regions must be of equal size.
According to http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html#t6 you can use this command-line option to control the region size:
-XX:G1HeapRegionSize=n: With G1 the Java heap is subdivided into uniformly sized regions. This sets the size of the individual sub-divisions. The default value of this parameter is determined ergonomically based upon heap size. The minimum value is 1Mb and the maximum value is 32Mb.
I hope this helps.
What's the maximum amount of heap space that one can allocate for java on a 64-bit platform? Is it unlimited?
Theoretically 264, but there might be limitations (obviously)
According to this FAQ it's only limited by memory and swap space on the local system:On 64-bit VMs, you have 64 bits of addressability to work with resulting in a maximum Java heap size limited only by the amount of physical memory and swap space your system provides.
See also Why can't I get a larger heap with the 32-bit JVM?
Also keep in mind you need to set the max heap via command line. Without an -Xmx command. without it Java uses 64mb + 30% = 83.2mb as a default max heap on 64 bit machines according the same FAQ.
java -Xmx1000g myClass
works fine on my machine. But it dosn't seem to yet support the 't' modifier so you can't specify max memory in terabytes yet :)
If you could make every atom in the universe into a byte of RAM, you could allocate it in a 64 bit address space.
Actually, that's a slight exaggeration.
There are 10^80 atoms in the universe (according to WolframAlpha), and 2^64 bytes of address space in a 64 bit system, so you'd only be able to address 1 out of every 5x10^60 atoms. But if you have 18 qintillion bytes of RAM, you'd probably need a couple of quantum black holes to power it with.
This probably depends on the system your VM is running in. If you are running a AMD x64 architecture the address space of currently shipped processors uses 48 Bits, not 64. This results in a theoretical maximum of roughly 256 TB. (See http://en.wikipedia.org/wiki/X86-64)
I am not a specialist in VMs, but any modern OS typically will give as much memory as there is physical RAM plus available virtual memory. Probably thats what the VM will pass to your application depending on its configuration.
With recent VMs from Sun, the practical heap limit size is usually 512 times the available physical and/or virtual memory. Even if the theoretical limit is much higher, the VM will allocate 1 byte for maangement purposes for each 512 bytes of heap memory on startup, so 1TB of heap will immediately require 2GB for the memory management.
In theory its between 2^63 and 2^64 bytes.
In practice it is limited by the amount of physical memory and swap space available on your machine. And the physical memory is in turn limited by your chipset (i.e. the number of address pins on the physical memory address bus) and motherboard (i.e. the number and size of the DIMM sockets).
I have a java app that uses about 15G on a machine with 16G. I don't know if I should set the max heap size.
If set will the jvm eat all the ram up to the limit and then start garbage collecting and stop everything while it churns through 15G of heap objects?
If not will the jvm hurt performance by not using all of the available ram on the machine.
My specific vm is: Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode).
Thanks
-Xmx15G will set the maximum heap size to 15 gig. Java will only allocate what it needs as it runs. If you don't set it, it will only use the default. For info on the default, see this post.
-Xms15G sets the minimum heap to 15 gig. This forces java to allocate 15 gig of heap space before it starts executing, whether it needs it or not.
Usually you can set them both to appropriate values depending on how you're tuning the JVM.
In Java 6, the default maximum heap size is determined by the amount of system memory present.
According to the Garbage Collector Ergonomics page, the maximum heap size is:
Smaller of 1/4th of the physical
memory or 1GB. Before J2SE 5.0, the
default maximum heap size was 64MB.
By using the -Xmx switch can be used to change the maximum heap size. See the java - the Java application launcher documentation for usage details.
If you don't set a max heap size (with -Xmx), isn't the default maximum only 64MB?
So won't your application fail with OutOfMemoryErrors if you don't set it? I'm confused on this question. How can your application run without this switch?
I have IBM's J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3) installed. After getting an OOM, the size of the heap dump is 383MB. How much heap does the JVM have?
The reason why I ask is that a 400MB heap dump seems a bit much for the default 64MB heap that I expect but I didn't specify any -Xm options. Does J9 use a different default heap size? If so, how can I find out what it is?
To print the current values, use:
java -verbose:sizes -version
According to the documentation, the default minimum and maximum heap sizes are platform-dependent. On most platforms, default -Xms is 4M. Default -Xmx for Linux is "Half the real memory with a minimum of 16 MB and a maximum of 512 MB", and for Windows, it's "Half the real memory with a minimum of 16 MB and a maximum of 2 GB".