Re: [Caml-list] OCaml GC [was Is OCaml fast?]

["Török Edwin" <edwintorok@gmail.com>]

On Sun, 28 Nov 2010 15:29:08 +0100
Benedikt Meurer <benedikt.meurer@googlemail.com> wrote:

> Speaking of the OCaml GC in general, wouldn't it make sense to
> replace the current generational collector with a collector framework
> that requires less copying in the common case. 

Even without changing the GC algorithm, I think it would be useful if we
could minimize the amount of "useless work" major collections do in the
current GC.
I profiled the binary trees with valgrind's callgrind, and it turns out
that most of the time for each minor collection is spent in
caml_major_collection_slice:
http://www.pasteall.org/pic/show.php?id=7194

This seems to be in concordance with the "smaller minor heap => more
minor collections => slower program" observation, since it is:
smaller minor heap => more minor collections => more major slices =>
major slices can't collect long-lived objects => slower program (long
lived objects are sweeped too many times).
So more minor collections => higher cost for a major slice

I think OCaml's GC should take into account how successful the last
major GC was (how many words it freed), and adjust speed accordingly:
if we know that the major slice will collect next to nothing there is
no point in wasting time and running it.

So this formula should probably be changed:
  p = (double) caml_allocated_words * 3.0 * (100 + caml_percent_free)
      / Wsize_bsize (caml_stat_heap_size) / caml_percent_free / 2.0;

Probably to something that also does:
  p =  p * major_slice_successrate

where successrate is how many words the GC succeeded in collecting the
last major slice (or last major collection).

I'm not familiar with OCaml's GC, but it looks like it doesn't keep
track of these stats during a collection, or does it?

P.S.: It would be good if this internal speed percentage was tunable
from the Gc module, at least by a constant factor.

Best regards,
--Edwin