Monero's FCMP++ Memory Proposal Now Respects Operator Settings

J-berman has revised a proposed Monero FCMP++ memory fix to preserve settings chosen by node operators. Pull request #11740, opened by j-berman on November 13 and updated November 14, addresses memory exhaustion reported during FCMP++ stressnet testing.

As checked on November 15, 2026, UTC, the PR remained open against master: reviewed, but not merged or released.

FCMP++ is a proposed change to Monero's transaction privacy proofs. The FCMP++ and Carrot stressnet is a separate test network.

Why memory remained high

J-berman reports out-of-memory failures on four-thread, 8 GB Linux stressnet machines despite earlier proof-verification optimizations. He attributes the remaining problem to glibc retaining memory and says limiting allocation arenas prevented most observed failures.

These developer-reported results were not independently reproduced for this article and do not establish a mainnet incident.

An allocation arena is an area through which the allocator manages memory. Freeing an object does not necessarily return its backing memory to the operating system immediately. The GNU C Library documentation describes separate controls for arena counts, heap trimming and memory retention. That distinction helps explain why reducing temporary working memory may leave a process's resident memory usage unexpectedly high.

Proposed allocator settings

The proposed code, revision 0029413, adds allocator configuration during daemon initialization.

Where glibc's M_ARENA_MAX facility is available, it proposes an arena ceiling equal to the greater of two or the compute thread pool's maximum concurrency. A configured concurrency of four produces a ceiling of four arenas. A concurrency of one produces two.

The November 14 revision first checks for MALLOC_ARENA_MAX, or an arena setting inside GLIBC_TUNABLES. When either is detected, it leaves the operator's configuration in place.

That matters because the earlier proposal could override an existing, lower arena limit. The revised behavior preserves deliberate tuning instead of silently raising that limit.

The automatic ceiling also follows compute concurrency, which can be influenced by --max-concurrency. It should not be described simply as the machine's physical core count. Platforms without the allocator facility do not receive the same adjustment.

An arena limit is not a RAM limit

The glibc documentation defines arena_max as a limit on the number of arenas. It does not assign each arena a fixed size or establish a maximum number of bytes the entire daemon may consume.

The proposed setting cannot by itself guarantee that a node will never run out of memory. Database activity, verification work and other allocations still matter when assessing a machine's capacity.

What node operators can do

For stressnet testing, a useful comparison would record the exact build, glibc version, concurrency and allocator environment, then measure peak resident memory, synchronization progress and any operating-system OOM events under comparable workloads. Keeping those variables consistent makes a before-and-after result more useful to reviewers.

Production operators should follow the PR through merge and release notes before treating it as an available fix.