RLIMIT_AS across posix_spawn and exec on Apple silicon: documented guarantees?

What supported behaviour, if any, may applications rely on for inherited RLIMIT_AS when launching a process on macOS on Apple silicon using posix_spawn and subsequent exec transitions?

An older published XNU header defines RLIMIT_AS:
XNU resource.h (immutable revision)
I am looking for the documented support and virtual-address-space accounting scope, including exclusions.

For a finite limit already set in the launching process, does any documented guarantee cover the new process from its first executable or dynamic-loader mapping and across later exec transitions, or does the limit take effect at a later stage? If the limit cannot be applied, does launch abort before any target user code executes, what failure is reported, and can mappings occur before that failure? An explicit statement that this guarantee is not provided would also be helpful.

My question concerns virtual address space, rather than resident memory or a language runtime's heap. A successful setter or getrlimit readback by itself does not answer when the limit takes effect.

If an answer relies on published XNU code, what public release/build record would be needed to relate an immutable source revision to a released macOS build on Apple silicon, and what limits apply to that correspondence? I am asking about the supported public interface and publicly available documentation/source, without requesting private implementation details.

A link to an existing answer or the documented boundary would be appreciated.

What high-level goal are you trying to achieve here?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks, Quinn.

Our high-level goal is to run local tests of our application’s draft-deletion and backup/restore workflows safely on a Mac with Apple silicon.

Each test run should operate on disposable test data, have bounded resource usage, and terminate cleanly if it exceeds its budget. We want to keep the host responsive and protect the main application and real user data. These are tests of our own application code.

The tests may launch a runtime and child processes. The memory-specific concern is preventing a faulty or runaway test from exhausting the host’s memory, including during process startup and subsequent exec transitions.

We were investigating RLIMIT_AS as a possible mechanism. What supported macOS API or isolation architecture would you recommend for this goal, and what memory-containment guarantees and limitations should we design around?

We’re looking for guidance on a supported approach; publicly documented guarantees or limitations would be sufficient.

Written by WhiteRabbit88 in 915678022

Our high-level goal is to run local tests of our application’s draft-deletion and backup/restore workflows

So you only need this for you test infrastructure?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"