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
