RFR: 8364248: Separate memory limit detection [v3]

[Joel Sikström]

On Tue, 29 Jul 2025 15:36:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > 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.
> 
> Maybe it depends on what you need and what question it should answer. Which I don't know. If the question is "what do you think I could allocate at most, were I to try now?"), then yes, allocatableMemory would be good name. It will always be a guess anyway.

I agree that it will always be a guess. What I believe a follow-up to this patch would do is to adjust os::allocatable_memory_limit() to take some user-configurable limit into account on Windows, like Job Objects, which is quite different from how the POSIX implementation works, so having two functions like we have now is needed in some way.

I'm open to chaning os::allocatable_memory_limit to something else, maybe something containing the word "commit", since that's what we actually care about. `os::commit_memory_limit()`?

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

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