A customer is reporting that G1 reports incorrect (low) Runtime.maxMemory(). Here's the e-mail:
I tried out G1 for the first time today and noticed that it reports a radically smaller value for Runtime.maxMemory() when compared to the same JVM without the G1 collector. Is that behavior expected? This was JDK 1.6.0_16 on Win32. I was planning to use Runtime.maxMemory() to set the capacity for the hard reference queue backing the weak value cache per the thread below. Is there actually less memory available with G1 or is the reported value wrong, in which case I could add a command line flag to directly specify the desired maximum bytes buffered for bigdata.
Here are the values reported for Runtime.maxMemory()
maxMemory=1009778688 when no garbage collector options are specified.
vs
maxMemory=15728640 when -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC is specified.
The other VM options are: -ea -server -Xmx1000m

EVALUATION
The reason for this is that we return the committed size from method G1CollectedHeap::max_capacity(), instead of the reserved size:
size_t G1CollectedHeap::max_capacity() const {
return _g1_committed.byte_size();
}