Originally posted 3/28 2007 on http://dev2dev.bea.com/blogs/hstahl. We haven't run on a bigger machine since, and I haven't seen anyone else claim the crown so I guess this "record" still stands.
I recently came across this old thread on TSS and just had to dig up an old log file I had lying around. I originally intended to post this last fall, but got sidetracked and forgot. Anyway - better late than never.
/opt/jrockit/bin/java -Xms3500g -Xmx3500g -XXgcthreads=1024 -XXlargepages ...
[memdbg ] Large pages enabled.
[memdbg ] Large pages for code enabled.
...
[memory ] GC strategy: parallel
[memory ] using large pages - maximal oldspace size commited at startup
[memory ] heap size: 3670016000K, maximal heap size: 3670016000K
...
[memdbg ] old collection 4 started
...
[gcpause] total mark time: 28786.228 ms
[memdbg ] ending marking phase
[memdbg ] starting parallel sweeping phase
...
[gcpause] total sweep time: 2380.615 ms
[memdbg ] ending sweeping phase
[gcpause] old collection phase 0 pause time: 31220.365000 ms, (start time: 3934.166 s)
[gcpause] (pause includes compaction: 1864.060 ms (internal), update ref: 657.861 ms)
[memdbg ] Page faults before GC: 4, page faults after GC: 4, pages in heap: 229376000
That ~30s pause time doesn't look so impressive until you realize that the heap size is not 3.5 gigabytes, but 3.5 TERABYTES!!!
Yes, we actually ran JRockit on an SGI Altix server with 512 dual-core Itanium CPUs using 1024 threads for parallel GC and 3.5 TB of heap - all in physical RAM. And this with a standard JRockit version, not some special prototype. So if you ever wondered how far you could scale your JRockit, now you know :-)
I have to admit that JRockit did not scale perfectly up to this size, but then this is hardly a typical configuration and you should be able to get reasonable performance and lower pause times by using our generational mostly-concurrent GC and doing some other command line tweaking.
