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.
Related
I have read couples of articles on java heap space and found out that the default max heap for JVM is 1/4th of the actual physical space. But none of the article had reason for this ?
Whats the reason of having it as 1/4th of actual memory?
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc-ergonomics.html
This dates back to JDK 5, which introduced JVM ergonomics. Prior to this, the JVM would set very small defaults for the heap space. JDK 1.1 had a default of 16Mb for both Xms and Xmx, JDK 1.2 changed this to Xms of 1Mb and Xmx of 64Mb by default. In JDK 1.3, Xms default increased to 2Mb.
Since Java was proving more popular on servers and memory capacities were increasing significantly, Sun introduced the concept of a server-class machine in JDK 5. This is one that has 2 or more physical processors and 2 or more Gb of memory (if I remember rightly, in JDK 5, the machine also had to not be running Windows to count as a server).
On server-class machines by default, the following parameters were set
Throughput garbage collector (i.e. the parallel collector)
initial heap size of 1/64 of physical memory up to 1Gbyte
maximum heap size of 1/4 of physical memory up to 1Gbyte
Server runtime compiler
Ergonomics provided two command-line flags that allowed a user to set a performance goal for the JVM; the idea being that the JVM would then figure out internally how to achieve this goal by modifying its parameters. The ultimate goal was to eliminate a lot of the -XX flags that were being used to tune JVM performance manually.
The parameters are:
-XX:MaxGCPauseMillis=nnn which sets the maximum pause time you want for GC in milliseconds.
-XX:GCTimeRatio= which sets the ratio of garbage collection time to application time being 1 / (1 + nnn). This was referred to as the throughput goal.
You can specify either of these goals or both. If the JVM manages to achieve both of these goals it then attempts to reduce the memory being used (the footprint goal).
There's more detail here:
https://www.oracle.com/technetwork/java/ergo5-140223.html
I've been profiling the x64 version of my application as the memory usage has been outrageously high, all of it seems to be coming from the JavaFX MediaPlayer, i'm correctly releasing listeners and eventhandlers.
Here is the stark contrast.
The x32 version at start
And now the x64 version at start
The x32 version stays below 256mb while the x64 will shoot over a gig; this is while both are left to play through their playlist.
All the code is the same.
JDK: jdk1.8.0_20
JRE: jre1.8.0_20
VM arguments on both
-XX:MinHeapFreeRatio=40 -XX:MaxHeapFreeRatio=70 -Xms3670k -Xmx256m -Dsun.java2d.noddraw=true -XX:+UseParallelGC
Same issue occurring on another x64 Java application
Is this a bug or am I overlooking something?
What you are seeing is the memory usage of the entire JVM running your process. The -Xmx256m setting only limits the maximum heap space available for your application to allocate (and the JVM would enforce that). Outside of heap space, the JVM can use additional memory for a host of other purposes (I am sure I will miss a few in the list below):
PermGen, which has now be replaced by the Metaspace. According to the documentation, there is no default limit for this:
-XX:MaxMetaspaceSize=size
Sets the maximum amount of native memory that can be allocated for class metadata. By default, the size is not limited. The amount of metadata for an application depends on the application itself, other running applications, and the amount of memory available on the system.
Stack space (memory used = (number of threads) * stack size. You can control this with the -Xss parameter
Off-heap space (either use of ByteBuffers in your code, or use of third pary libraries like EHCache which would in turn use off-heap memory)
JNI code
GC (garbage collectors need their own memory, which is again not part of the heap and can vary greatly depending on the collector used and the application memory usage)
In your case, you are seeing the "almost doubling" of memory use, plus probably a more relax Metaspace allocation when you move from a 32bit to a 64bit JVM. Using -XX:MaxMetaspaceSize=128m will probably bring the memory usage down to under 512MB for the 64bit JVM.
I don't know your application, respectively how it is implemented.
One possible reason for such a surprize differences could be how much memory can be used before a garbage collection is performed. It is thinkable that a machine with 64 bit words is allocated with more memory then a machine with 32 bit words. The garbage collector could run less often, so there would be more garbage memory still allocated, even when it is not really necessary or usefull.
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.
One would think it would be easy to find a table that lists the default maximum heap sizes for the different JVM versions...but a quick search didn't find such a thing.
So, what are the default maximum heap sizes for the various Sun JVM's?
I totally see the point in your question, since the JVM defaults differ by vendor and version. I would also be interested in a proper matrix. But all i have is Oracle Java 7 docs says:
The default value is chosen at runtime based on system configuration.
For server deployments, -Xms and -Xmx are often set to the same value.
For more information, see HotSpot Ergonomics
and deeper inside the docs it says:
The following changes take effect with J2SE 5.0. Garbage Collector of
Server VM Changed to Parallel Garbage Collector
On server-class machines running the server VM, the garbage collector
(GC) has changed from the previous serial collector (-XX:+UseSerialGC)
to a parallel collector (-XX:+UseParallelGC). You can override this
default by using the -XX:+UseSerialGC command-line option to the java
command. Initial Heap Size and Maximum Heap Size Changed for Parallel
Garbage Collector
On server-class machines running either VM (client or server) with the
parallel garbage collector (-XX:+UseParallelGC) the initial heap size
and maximum heap size have changed as follows.
Initial heap size: Larger of 1/64th of the machine's physical memory on the machine or some reasonable minimum. Before J2SE 5.0, the default initial heap size was a reasonable minimum, which varies by platform.
Maximum heap size: Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0, the default maximum heap size was 64MB.
Note: The boundaries and fractions given for the heap size are correct for J2SE 5.0. They are likely to be different in subsequent releases as computers get more powerful.
Jared, according to Java 1.5 documentation, the default max size is 64MB.
Take a look at -Xmsn and -Xmxn non-standard options.
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?