[gtkada] Garbage collection issues?

[ANH_VO at udlp.com]

Hi All,

I trust that Gtk+ manages the memory resources. On the other hand, I have a way
to prove that this is not the case. In fact, I have developed a utility (only on
package) to check if the memory is returned when the run is complete. Due to the
rule imposed by this chat, my utility can not be included in this mail. However,
I will send it directly to Emmanual for his evaluation. To prove my point I have
to rely on two test programs. One is the make.adb. The other is TestGtk.adb.
Here are the steps for testing it.

1. Insert the segment of code below
        Package_Name : aliased String := "Gtk.Button";
        Button_Pool : Storage_Pool_Handler.Detailed_Pool (
                 Size => 4_000, 
                 Max => Gtk_Button_Record'Max_Size_In_Storage_Elements,
                 User => Package_Name'Access);
        for Gtk_Button'Storage_Pool use Button_Pool;

to the end of package gtk.button.ads. Of course, package Storage_Pool_Handler
needs to be withed.

2. Rebuild make.adb. Once it is complete, run it. Memory should return to pool
successfully because no memory was needed for Gtk.Button.

3. Rebuild TestGtk.adb. Once it is complete, run it. Hit Containers
then Box several time. Finally, hit quit button. The memory leakage will be
shown as a result.

Anh Vo

____________________Reply Separator____________________
Subject:    Re: [gtkada] Garbage collection issues?
Author: <briot at gnat.com>
Date:       2/29/00 10:01 AM

 > Here is a cluster of observations and questions about memory management

I think this should go into a FAQ, this is a question that many people have
asked in the past. Unfortunately, we do not have a FAQ yet :-)

 > Some of the example programs shipping with GtkAda use a single variable
 > to catch the handles of multiple widgets as they are created, with the
 > result that the program afterward only has direct access to the last one
 > in the sequence.  Is that strategy suitable for a large program that may
 > run for hours and delete various windows along the way?  I.e., does
 > GtkAda (or the underlying GTK+) do any kind of automatic garbage
 > collection?

The short answer is "yes".
GtkAda takes care of almost all the memory management for you.
Here is a brief overview of how this works, you'll have to check the sources
if you want more detailled information.
gtk+ (the C library) does its own memory management through reference
counting, ie any widget is destroyed when it is no longer referenced anywhere
in the application. So as far as C objects are concerned, we did not have any
thing to do.
Now in GtkAda we associated a "user_data" which each C object that points to
the Ada tagged type that was allocated in the Gtk_New procedure. We also
register a "destroy" callback to be called when the object to which the
user_data belongs is destroyed (see Gtk.Initialize_User_Data).
Thus, every time a C object is destroyed, the equivalent Ada structure is also
destroyed (see Gtk.Free_User_Data).


 > If I delete a top-level window (or container), are the resources for its
 > component parts also deleted? Or do I need to create procedures to
 > recursively destroy all the lower-level components?

Every container holds a reference to its children, whose reference counting is
thus different from 0 (and generally 1). When the container is destroyed, the
reference of all its children and grand-children is decremented, and they are
destroyed in turn if needed.
So no need to create a complex procedure...

 > Finally, are all resources freed up when a program exits?  What if the
 > program exits abnormally?

I believe they should, but someone more knowledgeable about the inner workings
of X servers should answer (are the ressources automatically freed when the
application to which they belong crashes ?)

Emmanuel


_______________________________________________
gtkada mailing list
gtkada at gtkada.eu.org
http://gtkada.eu.org/cgi-bin/mailman/listinfo/gtkada
Received: from portal.udlp.com ([192.169.4.225]) by ccmail.udlp.com with SMTP
  (IMA Internet Exchange 3.13) id 00046769; Tue, 29 Feb 2000 02:59:12 -0600
Received: from portal.udlp.com (root at localhost)
    by portal.udlp.com with ESMTP id DAA11627
    for <anh_vo at udlp.com>; Tue, 29 Feb 2000 03:01:27 -0600 (CST)
Received: from ada.eu.org (marvin.enst.fr [137.194.161.2])
    by portal.udlp.com with ESMTP id DAA11623
    for <anh_vo at udlp.com>; Tue, 29 Feb 2000 03:01:26 -0600 (CST)
Received: from marvin.enst.fr (localhost [127.0.0.1])
    by ada.eu.org (Postfix) with ESMTP
    id E575E1907A; Tue, 29 Feb 2000 10:01:22 +0100 (CET)
Delivered-To: gtkada at gtkada.eu.org
Received: from lisbon.act-europe.fr (lisbon.act-europe.fr [195.25.32.163])
    by ada.eu.org (Postfix) with ESMTP id 7302419066
    for <gtkada at gtkada.eu.org>; Tue, 29 Feb 2000 10:01:19 +0100 (CET)
Received: (from briot at localhost)
    by lisbon.act-europe.fr (8.8.6 (PHNE_17190)/8.8.6) id KAA28025;
    Tue, 29 Feb 2000 10:01:18 +0100 (MET)
X-Authentication-Warning: lisbon.act-europe.fr: briot set sender to
briot at gnat.com using -f
From: <briot at gnat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14523.35546.844383.217245 at lisbon.act-europe.fr>
Date: Tue, 29 Feb 2000 10:01:14 +0100 (MET)
To: gtkada at gtkada.eu.org
Subject: Re: [gtkada] Garbage collection issues?
In-Reply-To: <38BB14D9.DBE60427 at mail.utexas.edu>
References: <38BB14D9.DBE60427 at mail.utexas.edu>
X-Mailer: VM 6.71 under Emacs 20.4.2
Reply-To: gtkada at gtkada.eu.org
Sender: gtkada-admin at gtkada.eu.org
Errors-To: gtkada-admin at gtkada.eu.org
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: GtkAda users mailing-list <gtkada.gtkada.eu.org>
X-BeenThere: gtkada at gtkada.eu.org