RFR: 8364248: Separate memory limit detection [v3]

Joel Sikström jsikstro at openjdk.org
Tue Jul 29 14:32:54 UTC 2025


On Tue, 29 Jul 2025 13:42:40 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:
> 
>   Rename os::has_allocatable_memory_limit() to os::allocatable_memory_limit()

Just want to start of by saying thank you for taking the time with this.

> I have some second thoughts about this. Sorry for the bikeshedding, but naming is important, especially since we never bother with comments on prototypes.
> 
> "allocatable_memory_limit" implies much more than it delivers. How much memory you can allocate depends on many factors, only one of which being the user-addressable address space size.
> 
> For example, how much you can _commit_ depends on OS, swap space size, OS-specific overcommit behavior etc. How much you can really use depends on how much memory you really have and how the OS is willing to give you. Etc.
> 
> I think it would be easier to clearly name this function as "address_space_limit" or similar, since that's what it is doing.

I agree that the naming is strong, but I don't see an issue with that. Like you're saying, on Linux (maybe all POSIX systems?), you can never commit more memory than you have virtual address space, regardless of OS, swap space size, and overcommit behavior. So a strong name for a strong upper-bound seems reasonable to me.

On POSIX, we only really need an os::address_space_limit(), since it answers both how much memory we can commit and the size of the virtual address space. On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit, which can be adjusted by the user, unlike the size of the virtual address space, which cannot be artificially limited. So I think we need both, so that both can be called from both OS's.

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

PR Comment: https://git.openjdk.org/jdk/pull/26530#issuecomment-3132826631


More information about the hotspot-gc-dev mailing list