GC and GTK+

[Owen Taylor <owt1 cornell edu>]

Some thoughts on the issue:

- Is GC a good thing?

At least theoretically, yes. GC can simplify memory management
drastically, and that is irrefutibly a good thing. Many people
also believe that it offers as good as, or better, performance
then manual memory mangagement. (Although examples of
high-performance GCed systems in the Unix world are still rare -
probably because of the dominance of C)

- Does GC solve multi-language memory management problems?

Not unless the same GC system is used for all languages. A cycle
that traverses two languages cannot be found unless the garbage
collector can walk the heap in both systems.

If GTK+ used a generic C language garbage collector, such as the
Boehm GC, it is possible that that collector could be used to
check the language-specific heap in addition to the language's
native memory management system.

This could be as simple as recompiling the interpreter with
-Dmalloc=GC_malloc. (etc.) However, a double penalty is then
exacted for memory management. If the language tries to do more
sophisticated GC than reference counting, there could be
major conflicts with GTK's garbage collector as well.

In any case, language bindings become much less attractive if
they require modifying the language runtime to work with GTK.

Very similar problems come up when considering writing GTK
frontends for large existing programs such as Mozilla or XEmacs.

- Could (a better) GC be used in the same way as reference
  counting is now?

Yes. Language bindings would just have to make sure that
any pointers to GTK objects were kept in traceable memory
blocks. This is a bit more complicated and more expensive
than interacting with reference counting, but quite doable.

- Could a "generic" GC layer be added to GTK ?

Only for a limited subset of garbage collectors. To do this
transparently without massive changes to existing code, the
fundemental units of heap allocation need to be pointers to
blocks of memory that are conservatively scanned for more heap
pointers. This is not going to be the case for something like
Scheme, where the allocation units will typically be structures
with additional pointers in well-defined places that the garbage
collector knows about.

A much more general class of garbage collectors could be used if
GTK used "handles" to the object structures instead of pointers.
With such a setup, any GC system where the units of heap
allocation can contain or point to conservatively scanned chunks
of memory would work. But as well as requiring massive changes to
existing code, it would either have a huge overhead, or require
GTK to be recompiled for each GC system.

- Could the Boehm Garbage Collector be used with GTK?

To get the Boehm GC working with pure C/GTK code would be a
fairly minor job. The main thing that would take attention is
making sure that unused pointers are NULL'd out.

The tricky part is finalization. Currently, GTK does fairly
heavy-weight finalization, and, in fact, will cause destruction
when the reference count drops to zero if that hasn't happened
before. The "destroy" callback is currently allowed to be
completely general code, and can even reacquire a reference count
to the destroyed object, preventing the true finalization
step.

Although the Boehm GC does allow for finalization, it can't
be that heavyweight, AFAIK. So some modifications would have
to be made:

 * Widgets that have existing X windows could never be 
   finalized. (The xid table would ensure this anyways)

 * The "destroy" signal should not be invoked if a widget
   gets finalized without being previously destroyed. (Such
   occurances are probably bugs in user code.) Garbage
   collection would make "destroy" handlers which purely 
   clean up allocated memory less necessary.

So while "minor", these changes would require fairly extensive
changes to every GTK program. I'm not sure the benefits
are worth such hassles, especially in light of the difficulties
that using GC would for things like language bindings.

The specialized allocators that GTK uses would also pose
somewhat of a hinderance for using GC. (For instance, all
list nodes are kept in a common pool and reused - so even
while using the Boehm GC, you would have manual "destruction"
for them.)

It could be an interesting research project, and GC could have big
benefits for a program like the GIMP that does extensive data
structure manipulation.

- What portability problems exist for using the Boehm GC?

The Boehm GC in general is probably as portable as GTK, if not
more so. However:

* It probably would only be acceptable for GUI programs in
  incremental mode. And support for that is much less widespread.
  (It requires access to the machines VM system)

* Porting GTK+ to new platforms would be a considerably more
  involved hurdle if the Boehm GC wasn't already ported.
  (Consider the question today about the Hurd)

* GTK+ is not (yet) thread safe, but it is possible to use
  in threaded programs. GC with threads requires close cooperation
  between the two systems, and the standard Boehm GC doesn't even
  come with an interface to POSIX threads. (From comments I've
  seen from Hans Boehm, the portable interface isn't sufficient
  for a GC system, since the GC needs to stop all threads to do
  its work)

These are in addition to the general problems with using GC
mentioned above.

My general opinion is that as attractive as a good GC system
is in some ways, it isn't really a practical choice for
GTK+ right now. The hybrid of manual destruction and reference
counting we have now may be about the best that can be done.

I haven't had a chance to look up attila's references yet,
so perhaps I'm quite wrong about this and good solutions
have been found to integrating multiple GC systems. Previous
research in this area is certainly very relevant.

However, to counter the impression that "Everybody has tried
reference counting and decided it is a bad idea" - a few
systems that I'm more familiar with that use reference counting
(or slight variants):

 - Perl
 - Python
 - ILU (the only system I know of to address memory management
   of objects in multiple interpreters simultaneously)
 - COM
 - The C++ and C mappings for CORBA

While those aren't all examples of stellar design, I think it
does show that reference counting is a workable techique in many
cases. To echo what some other people have said, I think that
general GC of C objects probably needs to mature and be
standardized more before it is useful in a system that is meant
to be as portable and interoperatable as GTK.

Regards,
                                        Owen
L