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

[Damien Doligez <Damien.Doligez@inria.fr>]

On 2010-11-29, at 23:27, Török Edwin wrote:

> 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

This is a bit naive, because the size of a major slice depends on the
amount of data promoted by the corresponding minor GC.  A smaller minor
heap promotes less data each time, so you get more major slices, but
they are smaller.  The total amount of work done by the major GC doesn't
change because of that.  It only changes because a bigger minor heap
gives more time for data to die before being promoted to the major heap.

> 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


The success rate is already taken into account by the major GC.  In fact
a target success rate is set by the user: it is
   caml_percent_free / (100 + caml_percent_free)
and the major GC adjusts its speed according to this target.  If the
target is not met, the free list is emptied faster than the GC can
replenish it, so it gets depleted at some point and the major heap
is then extended to satisfy allocation requests.  The bigger major
heap then helps the major GC meet its target, because the success rate
is simply (heap_size - live_data) / heap_size, and that gets higher
as heap_size increases.

I didn't do the math, but I think your modification would make the
major heap size increase without bound.

-- Damien