<div dir="ltr"><div><div><div><div><div><div><div><div>Hello all,<br><br></div>I was experimenting a bit with the JVM on a large memory system to which I have access, and I have a few questions.<br><br></div>The machine in question is a 72CPU E7-8895 x64 box running Solaris 11.3 with 1536GB of ram.    The machine has been up for some time, is idle with plenty of free memory and lots used up by ZFS file system caches.<br><br></div>So I wrote a simple Java program to populate a large array with Strings each 512 chars long (ie about 1K including the Java object overhead) and the randomly replace elements of the array with new String instances.   I could run this program up to size of about 350GB (jdk-9 G1GC) before the JVM would throw an error that it was unable to mmap large memory regions of 400GB in size.   <br><br></div>So I have a few questions/comments:<br><br></div>1) clearly G1GC in jdk9 is much better than G1GC in jdk8.  I suspect you know this already but in even the simplest testing it seemed clear that much has been improved.<br><br></div><br>2) is it really the case that the GC requires a large single mmap block to function?  This seems somewhat alarming to me as it's not clear how the OS is meant to <br><br><br></div>3) Is there a programmatic way, via some method call in Runtime.getRuntime() perhaps,  to collect the total cpu time used in GC in the current process?<br><br><br></div><div>4) I have access to this machine for some limited testing, so I'm hoping to run a JVM at 1TB of heap size....<br> <br></div><div><br></div>Here's the basic code block in question.   sizeMB is 256 * 1024, so the code is targetted to consume a bit more than 256GB<br><div><br>    public void build() {<br>        System.out.println("build");<br>        int size = sizeMB * 1024;<br>        list = new ArrayList<>(sizeMB * 1024);<br><br>        int count = 0;<br>        for (int i = 0; i < size; i++)<br>            list.add(i, getString());<br>    }<br><br></div><div>and here is how it fails:<br></div><div><br><br>[2.465s][info][gc] Using G1<br>build<br>[21.050s][info][gc] GC(0) Pause Young (G1 Evacuation Pause) 8608M->8585M(131072M) 13948.694ms<br>[23.073s][info][gc] GC(1) Pause Young (G1 Evacuation Pause) 14281M->14425M(131072M) 669.327ms<br>[25.120s][info][gc] GC(2) Pause Young (G1 Evacuation Pause) 20121M->20528M(131072M) 684.821ms<br>[27.261s][info][gc] GC(3) Pause Young (G1 Evacuation Pause) 26224M->26624M(131072M) 728.889ms<br>[34.630s][info][gc] GC(4) Pause Young (G1 Evacuation Pause) 32320M->32704M(393216M) 5983.418ms<br>[55.567s][info][gc] GC(5) Pause Young (G1 Evacuation Pause) 51520M->51888M(393216M) 9636.493ms<br>[74.421s][info][gc] GC(6) Pause Young (G1 Evacuation Pause) 69072M->69456M(393216M) 14334.621ms<br>[85.382s][info][gc] GC(7) Pause Young (G1 Evacuation Pause) 86640M->87056M(393216M) 6535.972ms<br>#<br># There is insufficient memory for the Java Runtime Environment to continue.<br># Native memory allocation (mmap) failed to map 365072220160 bytes for committing reserved memory.<br>Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x00007f2b40000000, 365072220160, 0) failed; error='Resource unavailable, try again' (errno=11<br>)<br># An error report file with more information is saved as:<br># /home/stange/IdeaProjects/GCScale/hs_err_pid23974.log<br><br><br></div><div>The JVM is run with -Xmx1234g -Xms128g -verbose:gc -XX:+UseG1GC<br></div><div><br><br><br></div></div>