## Object memory management

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). The methods which are used to manipulate this reference count are described below.

### Reference count

The functions `g_object_ref`/`g_object_unref` respectively increase and decrease the reference count. These functions are thread-safe. `g_clear_object` is a convenience wrapper around `g_object_unref` which also clears the pointer passed to it.

The reference count is initialized to one by `g_object_new` which means that the caller is currently the sole owner of the newly-created reference. When the reference count reaches zero, that is, when `g_object_unref` is called by the last client holding a reference to the object, the dispose and the finalize class methods are invoked.

Finally, after finalize is invoked, `g_type_free_instance` is called to free the object instance. Depending on the memory allocation policy decided when the type was registered (through one of the `g_type_register_*` 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 the section called “Instantiable classed types: objects” and the section called “Non-instantiable classed types: interfaces”.

The table below summarizes the destruction process of a GObject:

Table 5. `g_object_unref`

Invocation time | Function invoked | Function's parameters | Remark
--- | --- | --- | ---
Last call to `g_object_unref` for an instance of target type | target type's dispose class function | GObject instance | 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.
target type's finalize class function | GObject instance | 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 the section called “Reference counts and cycles”.
Last call to `g_object_unref` for the last instance of target type | interface's `interface_finalize` function | On interface's vtable | Never used in practice. Unlikely you will need it.
interface's `base_finalize` function | On interface's vtable | Never used in practice. Unlikely you will need it.
target type's `class_finalize` function | On target type's class structure | Never used in practice. Unlikely you will need it.
type's `base_finalize` function | On the inheritance tree of classes from fundamental type to target type. `base_init` is invoked once for each class structure. | Never used in practice. Unlikely you will need it.

### Weak References

Weak references are used to monitor object finalization: `g_object_weak_ref` 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).

`g_object_weak_unref` can be used to remove a monitoring callback from the object.

Weak references are also used to implement `g_object_add_weak_pointer` and `g_object_remove_weak_pointer`. 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.

Similarly, GWeakRef can be used to implement weak references if thread safety is required.

### Reference counts and cycles

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 in-between the two phases.

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 `g_object_run_dispose` 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.

This explains one of the rules about the dispose handler stated earlier: 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 `g_object_run_dispose` on one of the objects.

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 !

The above example, which might seem a bit contrived, can really happen if GObjects are being handled by language bindings — hence the rules for object destruction should be closely followed.