RFR: 8232722: G1 archive region deallocation may shrink the heap below -Xms

[Thomas Schatzl]

On Wed, 31 May 2023 13:13:26 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> > No real issue, but no real advantage either. In case of -Xms != -Xmx this would mean that the main method will not start with heap size of -Xms, but additional regions.
> 
> Right, that's the current behavior as well and not uncommitting the regions in `dealloc_archive_regions` doesn't change that. The difference appears only when the archive region mapping fails. If the regions are uncommitted it would bring back heap size to Xms. If not, heap size will remain slightly above Xms, which is same as the current behavior when mapping succeeds.

I do not think the current behavior is intended or good. It is at most tolerable. At least it has not been specified as correct in any documentation I could find, and it seems to counter to how initial heap size behaves with other collectors afaik (they just load the data into wherever it lands in old gen and fixes up references).

Hence filing https://bugs.openjdk.org/browse/JDK-8308854.

> The advantage is avoiding the need to track committed regions which avoids leaks more G1 specific details to CDS code. Adding GC policy specific details would make it harder to implement https://bugs.openjdk.org/browse/JDK-8296263. I am trying to move G1 specific code out of CDS in #14208. So if not uncommitting simplifies the things then why not?

That is a strange argument given that it causes some (minor) observable difference in behavior between collectors too. Having collectors behave the same helps reasoning about it.

I will look at the PR later today, haven't noticed it before.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14145#issuecomment-1571585857