You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
I can't reproduce the problem with your test program because some GC happen during the call to build and trigger the compaction, but I agree with your description of the problem.
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
The text was updated successfully, but these errors were encountered: