Intentional heap bounds change?

[Stefan Karlsson]

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://github.com/openjdk/jdk/commit/1ed5b22d6e48ffbebaa53cf79df1c5c790aa9d71#diff-74a766b0aa16c688981a4d7b20da1c93315ce72358cac7158e9b50f82c9773a3L567 
>
>
> 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
>