RFR: 8271195: Use largest available large page size smaller than LargePageSizeInBytes when available [v3]

Jatin Bhateja jbhateja at openjdk.java.net
Mon Feb 7 11:51:09 UTC 2022


On Mon, 7 Feb 2022 10:27:00 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> MAP_FIXED semantics are clear here, any existing reserved mapping will get overridden if a new commit happens over it, but only if new commit happens over the existing reserved address space, reservation takes a NULL address argument and returns the block of virtual memory which can be committed by binding it to large pages, since we are not bookkeeping the reserved memory space for any subsequent commit hence won't any unreserved virtual memory from a previous commit failure cause a leak in the virtual address space.
>
> I'm sorry, I don't fully follow your reasoning. Are you agreeing that this is not a problem?
> 
> To re-iterate what we have seen in the past: a reservation passing a NULL argument as the requested address is mapped on an address where a failed large page commit occurred (for this to happen, the previous reservation must have been release by the failure). This has lead us to require that the complete reservation is committed up front when using large pages, because we cannot risk loosing part of a reservation later in the execution. 
> 
> You can read more about this in the bug linked by @tstuefe and I think [this comments](https://bugs.openjdk.java.net/browse/JDK-8007074?focusedCommentId=13306490&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13306490) and the ones below explain the problem very well.

Yes, it seem this may turn to be not-a-bug.

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

PR: https://git.openjdk.java.net/jdk/pull/7326



More information about the hotspot-gc-dev mailing list