Bug ID: JDK-8267475 Heap size rounded up to large page size may cause excessive memory waste

Type: Enhancement
Component: hotspot
Sub-Component: gc
Affected Version: 17

Priority: P4
Status: Open
Resolution: Unresolved
OS: linux,windows

Submitted: 2021-05-20
Updated: 2022-02-21

Other
tbdUnresolved

If we start the VM with UseLargePages, we round up the heap size to the large page size:

https://github.com/openjdk/jdk/blob/aba22656829913d5f8d619a184c929a7de8431e4/src/hotspot/share/memory/universe.cpp#L815

Can be easily reproduced even on a normal (2g large pages) linux x64:

```
thomas@starfish:/shared/projects/openjdk$ ./jdk-jdk/output-fastdebug/images/jdk/bin/java -XX:+UseLargePages -Xmx32769k -Xlog:pagesize -version
...
[0.047s][info][pagesize] Heap:  min=8M max=34M base=0x00000000fde00000 page_size=2M size=34M
                                        ^^^
```

(We start with 32m+1k, but use 34m)

This is maybe acceptable for "small" large pages of 2MB, but with larger large pages this becomes an issue. 

See JDK-8267460, where a test error on an AARCH64 machine with 64k base- and 512m huge page size means that a VM started with 128m heap size and UseLargePages will grab a heap of 512m.

This calculation happens before reservation. If we then fail to grab a huge page, we will use up a virtual size of 512m, which is bearable (apart from the surprisingly large heap limit). But if we actually get a huge page, all that memory is committed and used right away.

I am sure we face the same issue with 1g pages on x64. But unfortunately I don't have a system with large large pages to test this. I am also not sure whether this would affect Windows.

I think logging a warning would be fine, e.g., if the heap size after aligning to page size would be more than x times the given size. E.g. x=2.0 would be noteworthy. I removed myself as assignee - feel free to close this issue if you think its not worth your time. I currently have no time to follow up on this.
09-07-2021
I've been looking into this a bit and an easy fix would be to say the we never round up the heap to the large page size. This would not really affect 2M pages since the heap alignment in most cases already is 2m at least. I took a quick look at enabling the heap to make use of mixed mappings, but I think that will be problematic, especially since the only OS supporting that is Linux. So we certainly want the heap size to be aligned to the heap size, at least if we are not looking to make a bigger change. Doing a bigger change might be the correct thing to look at for the long run, but that would certainly not be something for 17. So I wonder if instead should look at just adding some informational log or warning. I think log, to tell the user the heap-size was rounded up because large pages were used and the large page size is this. What do you think about that?
04-06-2021
Yes, Stefan J said something similar. IMHO a good solution would impose some sort of acceptable memory overhead caused by alignment. To distinguish the case of aligning a 127m heap to 128m on a 2m system - which is perfectly okay - from aligning a 127m heap to 512m - which may be surprising to the user. The latter should at least justify an unconditional warning, and maybe setting ULP=false. The problem arises IMHO if we run on a system where the only huge page size is very huge, and it gets chosen automatically without the user specifying LargePageSizeInBytes. Not everyone is aware that on an aarch64 64k pages system huge pages are 512m. They may not even be aware they run on a 64k paged system.
21-05-2021
I'm changing this to an enhancement because it has been an intentional decision (long ago) to round up heap size to large page size if the user requests large pages (for the heap). An "informed" user could simply not request large pages with a heap smaller than large page size. He needs to do some extra step to get large pages in either OS too, so the user is supposedly aware of what large pages are and what their sizes are (I mean, they need preallocation). Not disagreeing that the situation could not be handled better in some way, but please do not discount configuration error.
21-05-2021