Original bug ID: 7368
Reporter: amharc
Status: closed (set by @damiendoligez on 2016-09-28T09:28:21Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.03.0
Target version: 4.04.0 +dev / +beta1 / +beta2
Fixed in version: 4.04.0 +dev / +beta1 / +beta2
Category: runtime system and C interface
Monitored by: braibant @gasche

Bug description

When the programmer triggers the major collection manually using either Gc.major () or Gc.full_major (), the decision whether to compact the heap or not is based on a heuristic separate from the usual one. In particular, it does not compact the heap if it consists only of a single chunk. This was fine when the first chunk was never deallocated, but this has no longer been true since #5389: After a heap recompaction occurs, the heap consists of a single chunk, which can be arbitrarily large. If the programmer keeps triggering garbage collection manually, this chunk will not be compacted even if the live set size is small.

The attached program exhibits this behaviour: even though the live set is ca. 8 MB, the heap size is kept at ca. 14 GB.

Steps to reproduce

opam switch 4.03.0
eval opam config env
ocamlopt test.ml -o test
./test

File attachments

• 7368-test.ml