We have os::free_memory(). The purpose behind this (undocumented) function seems to be to release memory without uncommitting it. So, memory stays committed, does not have to be re-committed.
The only user seems to be ParallelGC.
On BSD, we use madvise with MADV_DONTNEED. On Linux, we re-commit over the existing paging.
madvise MADV_DONTNEED would be nicer since it is
- simpler (e.g. no need to bother with NMT memflags, seeJDK-8330076)
- safer (cannot fail. Committing can fail).
- hopefully (perhaps, this would have to be tested), works transparently with THP pages as well as static hugepages. If it does not work for the latter, it hopefully at least does no harm.
It would be nice if we could get rid of the pagesize parameter. That is possible if madvise does the right thing (preserves the current behavior) regardless of page size of the underlying memory.
The right thing would be:
- small pages and THP: free underlying memory
- hugepages: either also free underlying memory, without releasing the pages!, at least do nothing bad
At the very least we should rename this function. os::free_memory(address range) conflicts with the also existing os::free_memory() that queries the free memory on the system. Totally different things.
The only user seems to be ParallelGC.
On BSD, we use madvise with MADV_DONTNEED. On Linux, we re-commit over the existing paging.
madvise MADV_DONTNEED would be nicer since it is
- simpler (e.g. no need to bother with NMT memflags, see
- safer (cannot fail. Committing can fail).
- hopefully (perhaps, this would have to be tested), works transparently with THP pages as well as static hugepages. If it does not work for the latter, it hopefully at least does no harm.
It would be nice if we could get rid of the pagesize parameter. That is possible if madvise does the right thing (preserves the current behavior) regardless of page size of the underlying memory.
The right thing would be:
- small pages and THP: free underlying memory
- hugepages: either also free underlying memory, without releasing the pages!, at least do nothing bad
At the very least we should rename this function. os::free_memory(address range) conflicts with the also existing os::free_memory() that queries the free memory on the system. Totally different things.
- links to
-
Commit(master) openjdk/jdk/4a73ed44
-
Review(master) openjdk/jdk/20080