Merge pull request #9120 from mmottl/fix-minor-ratio-bug

Fix GC ratio multiplier bug
master
Gabriel Scherer 2019-11-15 13:47:19 +01:00 committed by GitHub
commit fa3dfaa6a8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 18 additions and 6 deletions

View File

@ -513,6 +513,10 @@ OCaml 4.10.0
and correct initialisation of some blocks allocated with caml_alloc_small.
(David Allsopp, review by Xavier Leroy)
- #9073, #9120: fix incorrect GC ratio multiplier when allocating custom blocks
with caml_alloc_custom_mem in runtime/custom.c
(Markus Mottl, review by Gabriel Scherer and Damien Doligez)
OCaml 4.09 maintenance branch:
------------------------------

View File

@ -89,12 +89,20 @@ CAMLexport value caml_alloc_custom_mem(struct custom_operations * ops,
{
mlsize_t mem_minor =
mem < caml_custom_minor_max_bsz ? mem : caml_custom_minor_max_bsz;
return alloc_custom_gen (ops, bsz, mem,
Bsize_wsize (Caml_state->stat_heap_wsz) / 150
* caml_custom_major_ratio,
mem_minor,
Bsize_wsize (Caml_state->minor_heap_wsz) / 100
* caml_custom_major_ratio);
mlsize_t max_major =
/* The major ratio is a percentage relative to the major heap size.
A complete GC cycle will be done every time 2/3 of that much memory
is allocated for blocks in the major heap. Assuming constant
allocation and deallocation rates, this means there are at most
[M/100 * major-heap-size] bytes of floating garbage at any time.
The reason for a factor of 2/3 (or 1.5) is, roughly speaking, because
the major GC takes 1.5 cycles (previous cycle + marking phase) before
it starts to deallocate dead blocks allocated during the previous cycle.
[heap_size / 150] is really [heap_size * (2/3) / 100] (but faster). */
Bsize_wsize (Caml_state->stat_heap_wsz) / 150 * caml_custom_major_ratio;
mlsize_t max_minor =
Bsize_wsize (Caml_state->minor_heap_wsz) / 100 * caml_custom_minor_ratio;
return alloc_custom_gen (ops, bsz, mem, max_major, mem_minor, max_minor);
}
struct custom_operations_list {