Re: [Caml-list] A question about GC.

[Philippe Wang <mail@philippewang.info>]

On Mon, Jun 13, 2011 at 2:19 PM, Guillaume Yziquel
<guillaume.yziquel@gmx.ch> wrote:
> Le Monday 13 Jun 2011 ą 14:34:07 (+0300), ygrek a écrit :
>> On Mon, 13 Jun 2011 12:37:46 +0200
>> Philippe Wang <mail@philippewang.info> wrote:
>>
>> > As far as I know, when OCaml's GC is not working as expected, it's
>> > (almost) always because there are blocks allocated outside OCaml's
>> > heap (a.k.a. custom blocks).
>>
>> Custom blocks are allocated on ocaml heap.
>
> No, not always. Nothing stops you from putting custom blocks outside of
> the ocaml heap. It might even sometimes make sense. Though usually
> you're fine allocating custom blocks on the ocaml heap with a pointer to
> out of heap data.
>
>> > How big are custom blocks? The bigger they are, the worst the behavior
>> > tends to be.
>>
>> Why?
>
> Because the GC relies on the two last arguments of caml_alloc_custom to
> properly evaluate the memory impact of allocating a custom block
> together with the data it refers to. It's easy to get it wrong for large
> data, and thus miscalibrate the GC on these blocks.
>
> However, the fact that grey values seem to accumulate doesn't seem to
> fit with such an simple explanation. But maybe Philippe is thinking
> about something else when talking about "big custom blocks allocated
> outside of the ocaml heap".

Let's consider this simple scenario:

 let tmp = new_very_large_data_outside_ocaml_heap () in
 let result = some_stuff(tmp) in
   result

=> if tmp is not useful anymore, you will probably have to wait a long
time before tmp is fully collected by the GC.
 That's because finalize functions are not called very often (as far
as I remember, so tell me if I'm wrong) notably not during a minor
collection, while finalize functions are those which actually free
those large data allocated outside OCaml's heap. So even if a minor
collection (or several)   is (are) triggered, memory is not collected
until a major collection.

This should explain why in some scenarios, even if C-interface is
written "perfectly", there is some "kind of memory-leak" (which is not
actual memory leak but just some delay on deallocations, which might
cause the program to fail).

The only way I know to deallocate quicker custom data is to trigger
the major collection more often. The only way to trigger the major
collection more often without calling Gc.something(), is to write the
program differently with a lot of small allocations ("a lot" means
"enough", here). Two ways: allocate dummy data (this is not really
good), allocate useful data (this is better). Allocating more data can
happen when programming with threads! When some computation is done
outside OCaml's heap, it's particularly relevant to use OCaml threads.
But this means at least one thread is computing "normal OCaml".

N.B. Well, maybe I'm not addressing the problem at all. Actually, what
I'm saying here is mostly based on my experiment with mlgmp (an
interface to use GMP in OCaml) about 5 years ago.

-- 
Philippe Wang
   mail@philippewang.info