Java 8 adding -XX:MaxNewSize to parameters

[Shawn Heisey]

I have a Solr install with the following info on the process list:

solr      4426     1 15 Sep27 ?        5-17:59:51 java -server -Xms7943m 
-Xmx7943m -XX:+UseG1GC -XX:+PerfDisableSharedMem 
-XX:+ParallelRefProcEnabled -XX:G1HeapRegionSize=8m 
-XX:MaxGCPauseMillis=250 -XX:InitiatingHeapOccupancyPercent=75 
-XX:+UseLargePages -XX:+AggressiveOpts -verbose:gc -XX:+PrintHeapAtGC 
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps 
-XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime 
-Xloggc:/data/solr-home/logs/solr_gc.log -XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=20M 
-Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.local.only=false 
-Dcom.sun.management.jmxremote.ssl=false 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.port=3000 
-Dcom.sun.management.jmxremote.rmi.port=3000 
-Djava.rmi.server.hostname=RWVM-SolrDev03 
-Dsolr.log.dir=/data/solr-home/logs -Djetty.port=8983 -DSTOP.PORT=7983 
-DSTOP.KEY=solrrocks -Dhost=RWVM-SolrDev03 -Duser.timezone=UTC 
-Djetty.home=/data/solr/server -Dsolr.solr.home=/data/solr-home/data 
-Dsolr.data.home= -Dsolr.install.dir=/data/solr 
-Dsolr.default.confdir=/data/solr/server/solr/configsets/_default/conf 
-Dlog4j.configuration=file:/data/solr-home/log4j.properties -Xss256k 
-Ddisable.configEdit=true -Xss256k -Dsolr.jetty.https.port=8983 
-Dsolr.log.muteconsole -XX:OnOutOfMemoryError=/data/solr/bin/oom_solr.sh 
8983 /data/solr-home/logs -jar start.jar --module=http

Process started Sep27, with G1 tuning, but no parameters setting 
specific generation sizes.

Here's the info at the top of a GC log written by that process:

2018-10-29 05:47:53 GC log file created /data/solr-home/logs/solr_gc.log.6
Java HotSpot(TM) 64-Bit Server VM (25.162-b12) for linux-amd64 JRE 
(1.8.0_162-b12), built on Dec 19 2017 21:15:48 by "java_re" with gcc 
4.3.0 20080428 (Red Hat 4.3.0-8)
Memory: 4k page, physical 16268024k(163252k free), swap 
2098172k(2056676k free)
CommandLine flags: -XX:+AggressiveOpts -XX:CICompilerCount=3 
-XX:ConcGCThreads=1 -XX:G1HeapRegionSize=8388608 
-XX:GCLogFileSize=20971520 -XX:InitialHeapSize=8329887744 
-XX:InitiatingHeapOccupancyPercent=75 -XX:+ManagementServer 
-XX:MarkStackSize=4194304 -XX:MaxGCPauseMillis=250 
-XX:MaxHeapSize=8329887744 -XX:MaxNewSize=4991221760 
-XX:MinHeapDeltaBytes=8388608 -XX:NumberOfGCLogFiles=9 
-XX:OnOutOfMemoryError=/data/solr/bin/oom_solr.sh 8983 
/data/solr-home/logs -XX:+ParallelRefProcEnabled 
-XX:+PerfDisableSharedMem -XX:+PrintGC 
-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps 
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC 
-XX:+PrintTenuringDistribution -XX:ThreadStackSize=256 
-XX:+UseCompressedClassPointers -XX:+UseCompressedOops 
-XX:+UseFastUnorderedTimeStamps -XX:+UseG1GC -XX:+UseGCLogFileRotation 
-XX:+UseLargePages

As you can see, the gc log says that -XX:MaxNewSize is among the 
parameters.  The problem came to my attention when I put the gc log into 
the gceasy.io website and it said "don't set your generation sizes 
explicitly, G1 works better when they aren't explicit."  Which I thought 
was weird, because I didn't know of anywhere that the sizes were being 
set.  I don't WANT to set the generation sizes explicitly.

I have confirmed by cross-referencing pids, checking which pid has the 
logfile open, and watching for new data written to the same log that it 
is indeed the same process, so I know the commandline arguments from the 
ps listing are from the right process.

Here's the version info for the java version that's running:

[solr at RWVM-SolrDev03 logs]$ java -version
java version "1.8.0_162"
Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)

I cannot reproduce the behavior manually on a Windows 10 machine,  
either with the same version that's on the Linux machine or using 
8u_191.  The machine where I see this happening is running CentOS 7.  
Hopefully I will be in a position to restart the service on the machine 
in the near future so I can check whether the issue is persistent.

I will attempt to reproduce on another Linux machine.  Does this seem 
like a bug?

Thanks,
Shawn