On Tue, 17 Mar 2026 19:59:49 GMT, Kurt Miller <[email protected]> wrote:

>> Not sure tbh, @bsdkurt or @battleblow may know more.
>
> I can comment as to why this came about for OpenBSD. OpenBSD default limits 
> are generally much lower than other OSs. What was happening is that configure 
> would set memory usage based on physmem but with OpenBSD's lower default data 
> rlimit that would be too high when the build machine had significantly more 
> physmem then the rlimit data size and would cause the jvm to fail.
> 
> man getrlimit(2) excerpt from OpenBSD: 
> 
>      RLIMIT_DATA     The maximum size (in bytes) of the data segment for a
>                      process; this includes memory allocated via malloc(3) and
>                      all other anonymous memory mapped via mmap(2).
> 
> whereas on FreeBSD it does not appear to include anonymous mmap memory:
> 
> RLIMIT_DATA     The  maximum  size (in bytes) of      the data segment for a
>                      process; this defines how far a program may extend  its
>                      break with the sbrk(2)
> 
> I suppose for FreeBSD `RLIMIT_AS` may make sense:
> 
>        RLIMIT_AS       The maximum amount (in bytes)  of  virtual  memory  the
>                      process is allowed to map.

Thanks @bsdkurt for clarifying. That makes sense. Interesting. OpenBSD is the 
first OS I know that includes mmap into RLIMIT_DATA. 

Do you know, by chance, if this also includes "uncommitted" mmapped memory  (as 
in, allocated with MAP_NORESERVE)? Since we over-allocate quite drastically 
with uncommitted memory.

Wait, I see that neither BSD nor MacOS manpages even mention MAP_NORESERVE. But 
we use it. Now I am confused :-)

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

PR Review Comment: 
https://git.openjdk.org/bsd-port/pull/4#discussion_r2951304732

Reply via email to