Final_tag and garbage collection

Final_tag and garbage collection

[Robbert VanRenesse]

The system that I'm building uses a mixture of C and CAML.  Sometimes it is
necessary to have references from CAML objects to C objects.  When CAML
cleans up its objects, the C objects need to be cleaned up as well.  I'm
using the finalization functionality of CAML for that.  However, it only
appears to work reliably in combination with alloc_shr(), not with alloc().
Here's the code:

	value link;

	link = alloc_shr(3, Final_tag);
	Field(link, 0) = (value) link_final;
	...

Very reliably, the function link_final is automatically invoked when the
system is garbage collecting.  However, if I use alloc() instead, it
sometimes happens, but lots of blocks appear to not get finalized.  I
used all of gc__minor, gc__major, and gc__fullmajor to try to provoke
finalization, but only a subset of what I allocated this way gets
finalized.

Any ideas?

				Robbert

Re: Final_tag and garbage collection

[Franck Delaplace]

We plan to develop an interface between Omega-calculator 0.96 (C++) and Camllight. The kernel 
has been already done (via external fucntion) but programming with this library is strongly imperative.
In order to have a functionnal approach of programming it suffices that the generated objects 
are  free by the  garbage collector. 

 Is there some way to tell the garbage collector to free some objects ?

Re: Final_tag and garbage collection

[Damien Doligez]

This is what I've replied to Robbert.  Forgot to do the Cc.  This may
be of interest to a few other people.

-- Damien

-----
>From doligez Tue Nov  7 14:25:42 1995
To: rvr@cs.cornell.edu
Subject: Re:  Final_tag and garbage collection

You're pointing to a lack of documentation here.  It's perfectly
normal that objects allocated in the minor heap don't get finalized,
because the minor GC is a copying GC, so it doesn't examine dead
objects.

The runtime of Caml Light version 0.7 has a function "alloc_final"
that you should use to allocate finalized objects.  It calls
alloc_shr.

The reasoning behind this design is that it would be very costly to
have the minor GC examine all dead objects to find the finalized
objects.  Moreover, calling the finalization function is moderately
costly, so the additional cost of garbage collection (caused by
bypassing the minor heap) is not too much overhead.

Please tell us if this is not the case in your application.

-- Damien
-----

[Robbert then told me that the GC is not finalizing his objects fast
enough, and asked what the parameters "mem" and "max" are used for in
alloc_final]

-----
>From doligez Wed Nov  8 14:49:10 1995
To: rvr@CS.Cornell.EDU
Subject: Re:  Final_tag and garbage collection

>Is it that alloc_shr blocks are allocated
>in the major heap, and it will just take a long time before I see the
>finalization of the alloc()'ed objects?

Yes.  The problem here is that the major GC speed (relative to the
program) is set by measuring the allocation rate of the program.  This
means that if your finalized objects are small, there may be a lot of
them in the state of "floating garbage" (unreferenced objects that the
GC has not yet collected), with huge amounts of resources referenced
(out of the heap) by these objects.

There is a workaround.

>I found alloc_final, but besides the size and a finalization function it
>also takes two arguments mem and max.  What are those for?

This is the workaround.  When you allocate a finalized object, you
specify what amount of out-of-heap resources it consumes, so the GC
knows it must work faster in order to collect these resources, and not
only the in-heap size of the object.  These out-of-heap resources may
be malloc'ed memory, or file descriptors, or whatever.  You give the
amount of resources allocated to this object as parameter "mem", and
the maximum amount that you want to see in floating garbage as
parameter "max".  The units are whatever you want (they are only used
relative to each other by the GC).

If you allocate several kinds of out-of-heap resources, you can use
different units in different calls to alloc_final.  This will make the
GC work faster than necessary (using more CPU time and less memory);
hopefully this will never become a problem.

I really need to document this.  Tell me if the above description is
clear enough.

-- Damien

P.S.  It may be the case that I'm off by a factor of two and the
      maximum amount of resources in floating garbage is twice "max".
      The calculations are tricky and I don't remember well.