Topic starter
02/08/2026 12:15 pm
TL;DR: OCaml 5 memory use could more than double on its interfile analysis workload until the major garbage collector was tuned dynamically, according to Semgrep research, with Memtrace and RSS measurements showing that static settings did not scale across repository sizes. The lesson is that runtime memory governance, not just language upgrades, becomes the control point when workload shape changes faster than default GC assumptions.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “Upgrading Semgrep from OCaml 4 to OCaml 5”.
Key questions
Q: Why do runtime upgrades sometimes increase memory use on the same workload?
A: Runtime upgrades can change garbage collection and allocation behaviour even when the application code does not change.
Q: How should teams choose GC settings when workload sizes vary widely?
A: Teams should tune garbage collection against representative workload classes instead of one median case.
Q: What are the signs that a memory regression is caused by GC behaviour?
A: A GC-driven regression usually shows up as higher RSS, slower reclamation of dead values, and a gap between live allocation traces and the process footprint the operating system sees.
Practitioner guidance
- Profile live memory and process RSS together Use both allocation tracing and operating-system memory polling when validating runtime changes so you can separate delayed collection from true footprint growth.
- Test runtime upgrades against representative workload sizes Benchmark small, medium, and large repositories separately, because the GC setting that works for one scan shape may degrade either latency or memory at another scale.
- Treat GC parameters as production controls Document which runtime parameters affect availability, assign ownership for them, and review them after language or runtime upgrades just as you would other capacity-sensitive settings.
Bottom line: OCaml 5 introduced a memory-behaviour change that exposed the limits of static GC assumptions in a real analysis workload.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:17 pm
Runtime memory governance is now part of security tooling reliability. When analysis engines, scanners, or policy services move to newer runtimes, the main failure mode is often not functional breakage but resource instability. That instability can degrade the controls downstream teams rely on, especially when a tool must finish work under bounded memory. The practitioner takeaway is to treat runtime tuning as a control-plane decision, not a purely engineering detail.
A question worth separating out:
Q: When should organisations use adaptive runtime controls instead of static defaults?
A: Use adaptive controls when workload shape, repository size, or traffic patterns vary enough that one default produces contradictory outcomes. In that situation, a single value forces a tradeoff between speed and memory that may be acceptable for one job and harmful for another. Adaptive tuning keeps the control aligned to current runtime conditions instead of stale assumptions.
👉 Read our full editorial: Dynamic garbage collection tuning for memory-heavy OCaml workloads