With the last example, here is the output of the test with OCAMLRUNPAM=v=1:

$ OCAMLRUNPARAM=v=1 ./eatmem.exe
=======================
ROUND 1
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
=======================
ROUND 2
=======================
ROUND 3
=======================
ROUND 4
=======================
ROUND 5
Fatal error: out of memory.

Setting OCAMLRUNPARAM=o=50 only delays the problem (crash at round 26).

Adding a call to Gc.major before the inner loop avoids the crash.

With OCAMLRUNPARAM=v=64 and grepping for "computed work", I observe that with 4.02, this amount remains around 1474537, while with 4.03, it oscillates a lot. Here is output of this grep piped to "uniq -c":

With the last example, here is the output of the test with OCAMLRUNPAM=v=1:

$ OCAMLRUNPARAM=v=1 ./eatmem.exe
=======================
ROUND 1
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
Starting new major GC cycle
=======================
ROUND 2
=======================
ROUND 3
=======================
ROUND 4
=======================
ROUND 5
Fatal error: out of memory.

Setting OCAMLRUNPARAM=o=50 only delays the problem (crash at round 26).

Adding a call to Gc.major before the inner loop avoids the crash.

With OCAMLRUNPARAM=v=64 and grepping for "computed work", I observe that with 4.02, this amount remains around 1474537, while with 4.03, it oscillates a lot. Here is output of this grep piped to "uniq -c":