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

Thomas Stuefe stuefe at openjdk.org
Thu Jul 31 05:15:54 UTC 2025


On Wed, 30 Jul 2025 13:47:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > 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.
> 

This makes sense and can also be read in conjunction with os::reserve_memory and os::commit_memory. As in 

// reserve_memory_limit() returns an upper limit beyond which os::reserve_memory
// calls are guaranteed to fail. It is not guaranteed reserving smaller sizes will succeed,
// however.

, and vice versa for commit_memory_limit.

> > 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?)

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

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


More information about the hotspot-gc-dev mailing list