RFR: 8364248: Separate memory limit detection from determining its size [v3]

[Joel Sikström]

On Wed, 30 Jul 2025 13:47:28 GMT, Albert Mingkun Yang <ayang 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 changing 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()`?
>
>> On Windows, we need an os::allocatable_memory_limit(), which would answer how much memory we can commit...
> 
> Based on this description, I'd think `commit_memory_limit` is more accurate in what this function returns. Taking a step further, I'd suggest `reserve_memory_limit` for `address_space_limit`; then it's obvious that they are semantically related and can be placed next to each other.
> 
>> to rename has_allocatable_memory_limit() to allocatable_memory_limit()...
> 
> I think PR25450 use bool-return to indicate error-or-not, which is quite diff here. Alternatively, is it possible to change the signature to `size_t x_limit(void)`, returning `size_max` when there is no limit? (Is there a semantic difference btw has-limit-at-size-max and no-limit?)

With some suggestions from @albertnetymk, I've changed `commit_memory_limit` to return size_t, just as `reserve_memory_limit`. I think this is reasonable since `commit_memory_limit` should always be bounded by what `reserve_memory_limit` returns anyway, so having both return size_t is good.

I also refactored some of code so that it fits better with the fact that `commit_memory_limit` always returns a value.

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

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