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

[Joel Sikström]

On Tue, 5 Aug 2025 06:42:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

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

Thank you for your input @dholmes-ora, and I agree that broader support for Job Objects, and by extension, native Windows containers, are possible in this space. I have nothing against creating an umbrella issue that covers adding support for native Windows containers. However, such containers were not my main focus, but an added benefit I suppose.

Using the size of the available virtual address space is a good indicator on how much memory can be committed, and will always be the absolute upper-bound. However, reading limits set by Job Object(s) is more complete IMO, since it (is the only way to?) limits how much memory can be committed, which is what this function is aiming to answer. So even though I think this overlaps with native Windows container support, I think this is a standalone enhancement as well.

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

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