Notifications
Clear all
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.
NHIMG editorial — based on content published by Semgrep: dynamic garbage collection tuning for OCaml 5 workloads
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: How should teams validate memory behaviour after a runtime upgrade?
A: Start with representative workloads, then measure peak memory, RSS, and runtime together before and after the change.
Q: When does static garbage collector tuning stop working?
A: Static tuning breaks down when the same setting must serve workloads with very different allocation patterns or heap sizes.
Q: What do teams get wrong about memory regressions in long-running services?
A: They often assume the problem is only application code, when the runtime may have changed the collector's behaviour or memory-return policy.
Practitioner guidance
- Implement workload-specific runtime benchmarks Run the same scan or analysis job across representative small, medium, and large inputs before and after an interpreter or runtime upgrade.
- Add dual-layer memory telemetry to production services Combine allocation tracing with OS-level RSS polling for the services that matter most.
- Adopt bounded, workload-aware tuning policies If one static GC setting cannot fit all workloads, define lower and upper bounds and adjust the collector based on a concrete runtime signal such as heap size.
What's in the full article
Semgrep's full post covers the implementation detail this analysis intentionally leaves at the architecture level:
- The exact Memtrace and RSS workflow used to compare OCaml 4 and OCaml 5 memory behaviour
- The dynamic_gc approach for adjusting GC settings after each major collection
- Repository-specific benchmark results across Juice Shop and Blaze Persistence
- The future work options, including live-memory tuning and more sophisticated controllers
👉 Read Semgrep's analysis of OCaml 5 memory regressions and GC tuning →
OCaml 5 memory regressions: what GC tuning changes for teams?
Explore further
02/08/2026 1:17 pm
Runtime tuning is part of operational governance, not a niche performance trick. Semgrep's experience shows that a platform upgrade can silently change the resource contract of a service even when application code is unchanged. For security and analysis tooling, that means upgrade management has to include measurement, rollback planning, and workload-specific validation. The practitioner lesson is to govern runtime behaviour with the same seriousness as access and deployment change.
A question worth separating out:
Q: Who should own runtime performance regressions in security tooling?
A: Ownership should sit with the team that runs the service, but change control should include engineering, operations, and security stakeholders if the tool feeds risk or access decisions. A runtime regression is not just a performance issue when it threatens scan reliability, pipeline stability, or decision quality.
👉 Read our full editorial: Dynamic garbage collection tuning for memory-heavy OCaml workloads
