RFR: 8364248: Separate memory limit detection from determining its size [v4]
Thomas Stuefe
stuefe at openjdk.org
Thu Jul 31 05:25:55 UTC 2025
On Wed, 30 Jul 2025 09:35:50 GMT, Joel Sikström <jsikstro at openjdk.org> wrote:
>> The function os::has_allocatable_memory_limit() is intended to determine whether there is a system-imposed limit on how much memory can be committed, and if so, what that limit is. On POSIX systems, limiting committable memory is typically enforced by restricting the available virtual address space, such as via RLIMIT_AS. As a result, os::has_allocatable_memory_limit() tells us both how much memory can be committed and how much virtual address space is available. On Windows however, os::has_allocatable_memory_limit() always returns true, along with the size of the available virtual address space. This is misleading because it is not possible to limit how much memory can be committed via virtual address space, and also the virtual address space cannot be limited.
>>
>> ZGC currently uses os::has_allocatable_memory_limit() to check if the virtual address space is limited. To make it clear that the virtual address space cannot be limited on Windows, I propose that we create a new function called os::has_limited_virtual_address_space() which simply returns false on Windows, since the virtual address space cannot be limited there.
>>
>> As a follow-up, I think it is reasonable to re-visit the implementation of os::has_allocatable_memory_limit() on Windows, since it doesn't follow any user-set limits, apart from how much virtual memory is available. Perhaps looking at limit(s) set by Job Objects could be more fruitful, and would improve the support for native Windows containers (Hyper-V).
>>
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Linux by limiting the virtual address space:
>>
>> $ ulimit -v 8388608 && java -XX:+UseZGC -Xlog:gc+init -version
>
> Joel Sikström has updated the pull request incrementally with one additional commit since the last revision:
>
> os:: unification in allocatable_memory_limit
src/hotspot/os/posix/os_posix.cpp line 716:
> 714:
> 715: #ifndef _LP64
> 716: // Helper, on 32bit, for os::allocatable_memory_limit
Pre-existing: paying for mmap only to later pay for the same mmap again seems overly costly, seeing that there is no guarantee anyway that the later mmap will also succeed.
src/hotspot/os/posix/os_posix.cpp line 813:
> 811:
> 812: // No limit
> 813: return SIZE_MAX;
This would be a very nice place to hook in the function I proposed you add, the sister function to `os::vm_min_address()`, let's call it `os::vm_max_address()`.
Looking through the ZGC sources, this is the functionality I meant: https://github.com/openjdk/jdk/blob/559795b0eb8061325127fa9fdf8b80617fe47166/src/hotspot/cpu/aarch64/gc/z/zAddress_aarch64.cpp#L45
For platforms that don't have that implementation, you can still return SIZE_MAX as fallback.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26530#discussion_r2244378549
PR Review Comment: https://git.openjdk.org/jdk/pull/26530#discussion_r2244374030
More information about the hotspot-gc-dev
mailing list