Intentional heap bounds change?

[Stefan Karlsson]

I logged a Bug for this:
https://bugs.openjdk.java.net/browse/JDK-8272364

Thanks,
StefanK

On 2021-08-11 13:04, Roman Kennke wrote:
> Hi,
>
> thanks for the comments. I have an example that shows the 'problem':
>
> http://cr.openjdk.java.net/~rkennke/Example.java
>
> Reproduce it using:
>
> java -Xms1g -Xmx4g -XX:+UseParallelOldGC -XX:MinHeapFreeRatio=10 
> -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 
> -XX:AdaptiveSizePolicyWeight=90 
> -Xlog:gc*=info,gc=debug,gc+heap*=trace,gc+ergo*=trace:file=gc.log:time,uptimemillis,level,tags 
> Example 300
>
> Check the heap log for heap size entries:
>
> grep "Pause Young" gc.log
>
> This yields the following:
>
> http://cr.openjdk.java.net/~rkennke/gc-heapsize.txt
>
> It shows that the heap is indeed shrinking well below -Xms, e.g. 
> ~600MB instead of 1024MB here:
>
> GC(12) Pause Young (Allocation Failure) 559M->589M(592M) 4,797ms
>
> Thanks for your help!
> Roman
>
>
>> Hi,
>>
>> On 2021-08-05 16:21, Roman Kennke wrote:
>>> Hello GC devs,
>>>
>>> I see a case where heap may shrink below -Xms. This may be 
>>> intentional or not. -Xms is initial heap size after all, not 
>>> necessarily minimum heap size. However, there is also documentation 
>>> that -Xms *does* provide the lower bounds for heap sizing policy, 
>>> e.g. [1]
>>
>> The documentation around this didn't reflect the actual 
>> implementation in HotSpot. As a part of recent cleanup and 
>> introduction of the -XX:InitialHeapSize flag, we updated the 
>> documentation to reflect the way -Xms is actually working:
>>
>> https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html
>> |
>> ---
>> -Xms| /size/
>>
>>     Sets the minimum and initial size (in bytes) of the heap. This value
>>     must be a multiple of 1024 and greater than 1 MB. Append the letter
>>     |k| or |K| to indicate kilobytes, |m| or |M| to indicate megabytes,
>>     |g| or |G| to indicate gigabytes. The following examples show how to
>>     set the size of allocated memory to 6 MB using various units:
>>
>>     |-Xms6291456 -Xms6144k -Xms6m|
>>
>>     Instead of the |-Xms| option to set both the minimum and initial
>>     size of the heap, you can use |-XX:MinHeapSize| to set the minimum
>>     size and |-XX:InitialHeapSize| to set the initial size."
>>
>> ---
>>
>>
>> Concretely, the code that parses -Xms sets both MinHeapSize and 
>> InitialHeapSize:
>>
>>
>>      } else if (match_option(option, "-Xms", &tail)) {
>>        julong size = 0;
>>        // an initial heap size of 0 means automatically determine
>>        ArgsRange errcode = parse_memory_size(tail, &size, 0);
>> ...
>>        if (FLAG_SET_CMDLINE(MinHeapSize, (size_t)size) != 
>> JVMFlag::SUCCESS) {
>>          return JNI_EINVAL;
>>        }
>>        if (FLAG_SET_CMDLINE(InitialHeapSize, (size_t)size) != 
>> JVMFlag::SUCCESS) {
>>          return JNI_EINVAL;
>>        }
>>
>>
>>>
>>> I believe this is due to this change:
>>>
>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/1ed5b22d6e48ffbebaa53cf79df1c5c790aa9d71*diff-74a766b0aa16c688981a4d7b20da1c93315ce72358cac7158e9b50f82c9773a3L567__;Iw!!ACWV5N9M2RV99hQ!Ydh0taE2rXnnONFDOoIBlbg_dh6YcXqA_2JPPqZUMWcQQvWFah7azM-toyRUxGwfAbPx$ 
>>>
>>>
>>> I.e. instead of adjusting old-gen minimum size with young-gen 
>>> minimum size, it is set to _gen_alignment.
>>>
>>> Is this intentional?
>>
>> Hopefully StefanJ will be able to answer this. The code has this 
>> comment, so maybe it is intentional?
>>
>> // Minimum sizes of the generations may be different than
>> // the initial sizes.  An inconsistency is permitted here
>> // in the total size that can be specified explicitly by
>> // command line specification of OldSize and NewSize and
>> // also a command line specification of -Xms.  Issue a warning
>> // but allow the values to pass.
>>
>> Do you have a command line that reproduces this problem?
>>
>> StefanK
>>
>>>
>>> Thanks,
>>> Roman
>>>
>>>
>>> [1] 
>>> https://docs.oracle.com/en/java/javase/11/gctuning/factors-affecting-garbage-collection-performance.html#GUID-B0BFEFCB-F045-4105-BFA4-C97DE81DAC5B
>>>
>>
>