Minor heap sizing after the OCaml 5.x multicore GC transition: retuning -I for parallel workloads

OCaml 5.0 replaced the single-threaded runtime with a multicore-capable one, including a parallelized garbage collector where each domain allocates into its own minor heap arena before promotion to the shared major heap. Tuning guidance written for the 4.x runtime — for example, enlarging the minor heap via the -I runtime parameter or OCAMLRUNPARAM to reduce promotion pressure — no longer maps cleanly onto this model.

The goal is to establish a defensible sizing policy for the per-domain minor heap on a service running several domains with allocation-heavy, short-lived workloads, where the legacy heuristic of "grow the minor heap until major collections become rare" was tuned against a single stop-the-world collector. It is unclear whether per-domain minor heaps should be sized independently of domain count, or whether aggregate arena memory and synchronization of the major collection phase change the trade-off. Gc.stat counters are available for observation, but their interpretation across domains is not obvious.

Assuming OCaml 5.1+ and stock runtime flags:

• Is the -I minor heap setting applied per domain, and does the optimal value scale down as domain count increases?
• Which Gc statistics best indicate that minor heap size, rather than cross-domain synchronization, is the bottleneck?
• Are there documented behavioral differences in promotion policy between 4.x and 5.x that invalidate older tuning rules?