| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> |
| <title>Object memory management</title> |
| <meta name="generator" content="DocBook XSL Stylesheets V1.75.2"> |
| <link rel="home" href="index.html" title="GObject Reference Manual"> |
| <link rel="up" href="chapter-gobject.html" title="The GObject base class"> |
| <link rel="prev" href="chapter-gobject.html" title="The GObject base class"> |
| <link rel="next" href="gobject-properties.html" title="Object properties"> |
| <meta name="generator" content="GTK-Doc V1.14 (XML mode)"> |
| <link rel="stylesheet" href="style.css" type="text/css"> |
| </head> |
| <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> |
| <table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="2"><tr valign="middle"> |
| <td><a accesskey="p" href="chapter-gobject.html"><img src="left.png" width="24" height="24" border="0" alt="Prev"></a></td> |
| <td><a accesskey="u" href="chapter-gobject.html"><img src="up.png" width="24" height="24" border="0" alt="Up"></a></td> |
| <td><a accesskey="h" href="index.html"><img src="home.png" width="24" height="24" border="0" alt="Home"></a></td> |
| <th width="100%" align="center">GObject Reference Manual</th> |
| <td><a accesskey="n" href="gobject-properties.html"><img src="right.png" width="24" height="24" border="0" alt="Next"></a></td> |
| </tr></table> |
| <div class="sect1" title="Object memory management"> |
| <div class="titlepage"><div><div><h2 class="title" style="clear: both"> |
| <a name="gobject-memory"></a>Object memory management</h2></div></div></div> |
| <p> |
| The memory-management API for GObjects is a bit complicated but the idea behind it |
| is pretty simple: the goal is to provide a flexible model based on reference counting |
| which can be integrated in applications which use or require different memory management |
| models (such as garbage collection, aso...). The methods which are used to |
| manipulate this reference count are described below. |
| </p> |
| <pre class="programlisting"> |
| /* |
| Refcounting |
| */ |
| gpointer g_object_ref (gpointer object); |
| void g_object_unref (gpointer object); |
| |
| /* |
| * Weak References |
| */ |
| typedef void (*GWeakNotify) (gpointer data, |
| GObject *where_the_object_was); |
| |
| void g_object_weak_ref (GObject *object, |
| GWeakNotify notify, |
| gpointer data); |
| void g_object_weak_unref (GObject *object, |
| GWeakNotify notify, |
| gpointer data); |
| void g_object_add_weak_pointer (GObject *object, |
| gpointer *weak_pointer_location); |
| void g_object_remove_weak_pointer (GObject *object, |
| gpointer *weak_pointer_location); |
| /* |
| * Cycle handling |
| */ |
| void g_object_run_dispose (GObject *object); |
| </pre> |
| <p> |
| </p> |
| <div class="sect2" title="Reference count"> |
| <div class="titlepage"><div><div><h3 class="title"> |
| <a name="gobject-memory-refcount"></a>Reference count</h3></div></div></div> |
| <p> |
| The functions <code class="function"><a class="link" href="gobject-The-Base-Object-Type.html#g-object-ref" title="g_object_ref ()">g_object_ref</a></code>/<code class="function"><a class="link" href="gobject-The-Base-Object-Type.html#g-object-unref" title="g_object_unref ()">g_object_unref</a></code> respectively |
| increase and decrease the reference count.These functions are thread-safe as of GLib 2.8. |
| The reference count is, unsurprisingly, initialized to one by |
| <code class="function"><a class="link" href="gobject-The-Base-Object-Type.html#g-object-new" title="g_object_new ()">g_object_new</a></code> which means that the caller |
| is currently the sole owner of the newly-created reference. |
| When the reference count reaches zero, that is, |
| when <code class="function"><a class="link" href="gobject-The-Base-Object-Type.html#g-object-unref" title="g_object_unref ()">g_object_unref</a></code> is called by the last client holding |
| a reference to the object, the <span class="emphasis"><em>dispose</em></span> and the |
| <span class="emphasis"><em>finalize</em></span> class methods are invoked. |
| </p> |
| <p> |
| Finally, after <span class="emphasis"><em>finalize</em></span> is invoked, |
| <code class="function"><a class="link" href="gobject-Type-Information.html#g-type-free-instance" title="g_type_free_instance ()">g_type_free_instance</a></code> is called to free the object instance. |
| Depending on the memory allocation policy decided when the type was registered (through |
| one of the <code class="function">g_type_register_*</code> functions), the object's instance |
| memory will be freed or returned to the object pool for this type. |
| Once the object has been freed, if it was the last instance of the type, the type's class |
| will be destroyed as described in <a class="xref" href="gtype-instantiable-classed.html" title="Instantiable classed types: objects">the section called “Instantiable classed types: objects”</a> and |
| <a class="xref" href="gtype-non-instantiable-classed.html" title="Non-instantiable classed types: interfaces">the section called “Non-instantiable classed types: interfaces”</a>. |
| </p> |
| <p> |
| The table below summarizes the destruction process of a GObject: |
| </p> |
| <div class="table"> |
| <a name="gobject-destruction-table"></a><p class="title"><b>Table 5. <code class="function"><a class="link" href="gobject-The-Base-Object-Type.html#g-object-unref" title="g_object_unref ()">g_object_unref</a></code></b></p> |
| <div class="table-contents"><table summary="g_object_unref" border="1"> |
| <colgroup> |
| <col align="left"> |
| <col align="left"> |
| <col align="left"> |
| </colgroup> |
| <thead><tr> |
| <th align="left">Invocation time</th> |
| <th align="left">Function Invoked</th> |
| <th align="left">Function's parameters</th> |
| <th>Remark</th> |
| </tr></thead> |
| <tbody> |
| <tr> |
| <td rowspan="2" align="left">Last call to <code class="function"><a class="link" href="gobject-The-Base-Object-Type.html#g-object-unref" title="g_object_unref ()">g_object_unref</a></code> for an instance |
| of target type |
| </td> |
| <td align="left">target type's dispose class function</td> |
| <td align="left">GObject instance</td> |
| <td> |
| When dispose ends, the object should not hold any reference to any other |
| member object. The object is also expected to be able to answer client |
| method invocations (with possibly an error code but no memory violation) |
| until finalize is executed. dispose can be executed more than once. |
| dispose should chain up to its parent implementation just before returning |
| to the caller. |
| </td> |
| </tr> |
| <tr> |
| <td align="left">target type's finalize class function</td> |
| <td align="left">GObject instance</td> |
| <td> |
| Finalize is expected to complete the destruction process initiated by |
| dispose. It should complete the object's destruction. finalize will be |
| executed only once. |
| finalize should chain up to its parent implementation just before returning |
| to the caller. |
| The reason why the destruction process is split is two different phases is |
| explained in <a class="xref" href="gobject-memory.html#gobject-memory-cycles" title="Reference counts and cycles">the section called “Reference counts and cycles”</a>. |
| </td> |
| </tr> |
| <tr> |
| <td rowspan="4" align="left">Last call to <code class="function"><a class="link" href="gobject-The-Base-Object-Type.html#g-object-unref" title="g_object_unref ()">g_object_unref</a></code> for the last |
| instance of target type |
| </td> |
| <td align="left">interface' interface_finalize function</td> |
| <td align="left">On interface' vtable</td> |
| <td>Never used in practice. Unlikely you will need it.</td> |
| </tr> |
| <tr> |
| <td align="left">interface' base_finalize function</td> |
| <td align="left">On interface' vtable</td> |
| <td>Never used in practice. Unlikely you will need it.</td> |
| </tr> |
| <tr> |
| <td align="left">target type's class_finalize function</td> |
| <td align="left">On target type's class structure</td> |
| <td>Never used in practice. Unlikely you will need it.</td> |
| </tr> |
| <tr> |
| <td align="left">type's base_finalize function</td> |
| <td align="left">On the inheritance tree of classes from fundamental type to target type. |
| base_init is invoked once for each class structure.</td> |
| <td>Never used in practice. Unlikely you will need it.</td> |
| </tr> |
| </tbody> |
| </table></div> |
| </div> |
| <p><br class="table-break"> |
| </p> |
| </div> |
| <div class="sect2" title="Weak References"> |
| <div class="titlepage"><div><div><h3 class="title"> |
| <a name="gobject-memory-weakref"></a>Weak References</h3></div></div></div> |
| <p> |
| Weak References are used to monitor object finalization: |
| <code class="function"><a class="link" href="gobject-The-Base-Object-Type.html#g-object-weak-ref" title="g_object_weak_ref ()">g_object_weak_ref</a></code> adds a monitoring callback which does |
| not hold a reference to the object but which is invoked when the object runs |
| its dispose method. As such, each weak ref can be invoked more than once upon |
| object finalization (since dispose can run more than once during object |
| finalization). |
| </p> |
| <p> |
| <code class="function"><a class="link" href="gobject-The-Base-Object-Type.html#g-object-weak-unref" title="g_object_weak_unref ()">g_object_weak_unref</a></code> can be used to remove a monitoring |
| callback from the object. |
| </p> |
| <p> |
| Weak References are also used to implement <code class="function"><a class="link" href="gobject-The-Base-Object-Type.html#g-object-add-weak-pointer" title="g_object_add_weak_pointer ()">g_object_add_weak_pointer</a></code> |
| and <code class="function"><a class="link" href="gobject-The-Base-Object-Type.html#g-object-remove-weak-pointer" title="g_object_remove_weak_pointer ()">g_object_remove_weak_pointer</a></code>. These functions add a weak reference |
| to the object they are applied to which makes sure to nullify the pointer given by the user |
| when object is finalized. |
| </p> |
| </div> |
| <div class="sect2" title="Reference counts and cycles"> |
| <div class="titlepage"><div><div><h3 class="title"> |
| <a name="gobject-memory-cycles"></a>Reference counts and cycles</h3></div></div></div> |
| <p> |
| Note: the following section was inspired by James Henstridge. I guess this means that |
| all praise and all curses will be directly forwarded to him. |
| </p> |
| <p> |
| GObject's memory management model was designed to be easily integrated in existing code |
| using garbage collection. This is why the destruction process is split in two phases: |
| the first phase, executed in the dispose handler is supposed to release all references |
| to other member objects. The second phase, executed by the finalize handler is supposed |
| to complete the object's destruction process. Object methods should be able to run |
| without program error (that is, without segfault :) in-between the two phases. |
| </p> |
| <p> |
| This two-step destruction process is very useful to break reference counting cycles. |
| While the detection of the cycles is up to the external code, once the cycles have been |
| detected, the external code can invoke <code class="function">g_object_dispose</code> which |
| will indeed break any existing cycles since it will run the dispose handler associated |
| to the object and thus release all references to other objects. |
| </p> |
| <p> |
| Attentive readers might now have understood one of the rules about the dispose handler |
| we stated a bit sooner: the dispose handler can be invoked multiple times. Let's say we |
| have a reference count cycle: object A references B which itself references object A. |
| Let's say we have detected the cycle and we want to destroy the two objects. One way to |
| do this would be to invoke <code class="function">g_object_dispose</code> on one of the |
| objects. |
| </p> |
| <p> |
| If object A releases all its references to all objects, this means it releases its |
| reference to object B. If object B was not owned by anyone else, this is its last |
| reference count which means this last unref runs B's dispose handler which, in turn, |
| releases B's reference on object A. If this is A's last reference count, this last |
| unref runs A's dispose handler which is running for the second time before |
| A's finalize handler is invoked ! |
| </p> |
| <p> |
| The above example, which might seem a bit contrived can really happen if your |
| GObject's are being handled by language bindings. I would thus suggest the rules stated above |
| for object destruction are closely followed. Otherwise, <span class="emphasis"><em>Bad Bad Things</em></span> |
| will happen. |
| </p> |
| </div> |
| </div> |
| <div class="footer"> |
| <hr> |
| Generated by GTK-Doc V1.14</div> |
| </body> |
| </html> |
