Re: lablgtk missing macros to live in harmony with the garbage collector

On 2015/01/28 03:52, Felix Ruess wrote:
> 
> Hi guys,
> 
> I noticed that our applications seem to use more and more memory the longer they run.
> Profiling it, it looks like most of it is coming from closures that use GObj and GtkSignal.
> 
> It looks like most parts of lablgtk don't properly use the CAMLparam, CAMLreturn, etc macros that are described here: http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html#sec440
> Fixing a similar issue in some of our code interfacing with C made a HUGE difference.

The way GC related macros are use in LablGtk comes from the fact it was originally
developed before the introduction of the CAMLparam, and used an old set of macros.
As a result, the registration of roots is optimized (we do not register roots when there is
no risk of the GC changing them).
Anyway, the absence of these macros can in some cases cause memory corruption,
but not a loss in performance. (Of course, registering but forgetting to release them causes
memory leaks, but not registering them in the first place doesn't).

As Claude explains, memory problems with LablGtk are more related to the way external
resources are handled by the GC. LablGtk tries to automate most things, so that you don't
have to finalize by hand. However it only works if the GC is called often enough, and
there is no good way to control that in the ocaml runtime. The reset_gc Claude describes
improves performance by actually running the GC less often, but there is a risk of augmenting
the memory consumption. You could combine it with running Gc.major or Gc.full_major
manually once in a while.

> E.g. the ml_g_signal_override_class_closure function in ml_gobject.c does not use these macros...
> Any particular reason for that? Am I missing something here, or is that a bug (or rather lots of bugs)?


Since this function does not allocate, the GC will never run during its execution, so
there is no need to protect its variables.

	Jacques