Re: [Caml-list] The GC is not collecting... my mistake?

[Alain Frisch <alain@frisch.fr>]

Markus Mottl wrote:
> If you compile this to native code, running "foo 1" will print "1"
> followed by "2".  If you run "foo 2" it will print "1", then
> "finalized", then "2".  Byte code will only print "1" and "2" in any
> case - hm, weird.

For bytecode, this is an expected behavior: the back-end does not emit 
any information that would allow the runtime system to know which value 
on the stack is still live (at each possible GC point). The behavior in 
native code is an optimization which lets the GC reclaim more memory, 
but AFAIK, this is not specified. The safe assumption is that a value 
identifier forces the value to remain live in all its syntactic scope 
(this is not a formal definition; for instance, a tail call terminates 
the scope of identifiers defined at the call site).

> Obviously, OCaml does not reclaim the tuple during the allocation loop
> even though it could (and IMHO should).  This can introduce
> substantial space leaks as happened to us.

I agree this might be surprising, but since I don't see the behavior 
changing for bytecode anyway, I don't think it is worth dealing with 
this case in native code (any program that relies on the improved 
behavior you ask for would have an unexpected behavior in bytecode).

The proper solution might be to reflect in the syntactic scope your 
desire to see some value reclaimed:

let main2 () =
   let b =
     let a, b = alloc () in
     Gc.finalise finaliser a;
     print_len a;
     b
   in
   (* Here a is no longer visible and can thus be reclaimed. *)
   alloc_loop ();
   print_len b

This works in bytecode as well.


Alain