RFR: 8364518: Support for Job Objects in os::commit_memory_limit() on Windows [v2]

[David Holmes]

On Mon, 4 Aug 2025 07:40:12 GMT, Joel Sikström <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> We currently use os::commit_memory_limit() to limit the initial, min and max values when ergonomically setting the heap size. Right now, os::commit_memory_limit() returns the available virtual address space on Windows, which is guaranteed to be the upper-bound of how much memory can be committed. However, this does not take into account user-configurable limits.
>> 
>> I propose revising os::commit_memory_limit() to consider Windows Job Objects. Job Objects can, among other things, restrict the amount of memory that can be committed by a single process or all processes in a job. If we are unable to query Job Object information or if no limit is set, I suggest returning SIZE_MAX, since the next effective limit is the available virtual address space. The size of this virtual address space cannot be modified by the user, except by consuming it. 
>> 
>> For more details and short examples, I have created a GitHub repository summarizing my findings regarding memory limits and Job Objects on Windows: [https://github.com/jsikstro/MemoryLimitsWindows ](https://github.com/jsikstro/MemoryLimitsWindows).
>> 
>> Adding support for Job Objects in this way adds support for detecting memory limits when using native Windows Hyper-V containers, which uses Job Objects to limit memory.
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Manual testing on Windows using both [Process Governor](https://github.com/lowleveldesign/process-governor) (a popular tool), and creating a Job Object manually.
>
> Joel Sikström has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Print error message if query fails

I can't help but think that this should be part of a broader effort to support "containers" on Windows. We allowed the use of JobObjects for the processor count because it was similar what you could do with cpu-sets on Linux and not fundamentally "container" related. What you propose here looks good, but surely there are more things that need to be adjusted to account for JobObjects in this space? Case in point I just raised a query today about why we have a confused notion of "physical memory" on Linux, depending on whether you are running in a container or not. I would suspect a similar distinction would need to be made on Windows if running under JobObjects.

To be clear I have no issue with the current PR providing this part of Windows "container" support, but I would like to see at least an Umbrella JBS issue (JEP?) created to cover everything that would be needed for such support. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/26593#issuecomment-3153708050