This article will explain the memory management in AngelScript in detail. It's probably more detail than most developers need to know, but some may want to know exactly how it works in order to evaluate AngelScript better.
AngelScript uses a hybrid method with both reference counting and garbage collection, where reference counting is the main method and the garbage collection is only for backup when circular references needs to be resolved.
This design was chosen because reference counting is the easiest way of passing objects between script engine and application while still keeping track of live objects. If pure garbage collection was used, the script engine would have to know about the entire memory space of the application where script objects could be stored, otherwise it wouldn't be able to know if the objects are still alive or not.
The garbage collector is only used for those object types that have a possibility of forming a circular reference with itself or other objects, e.g. objects that have a member variable as a handle to the same type as itself. Whenever such an object is created, the garbage collector is informed so that it can keep track of the object.
The garbage collector is not executed manually, because the application will want to control when that extra processing should be done, usually at idle moments of the application execution. The garbage collector in AngelScript is also incremental, so that it can be executed in tiny steps throughout the application execution.
All built-in script objects are automatically reference counted, and the application just need to make sure to call the AddRef and Release methods appropriately if it is storing any references to the objects outside the script engine.
Application registered objects may or may not be reference counted. Those that should be reference counted must implement the ADDREF and RELEASE behaviours so that AngelScript can notify the objects of the changes to the reference count. The application needs keep track of the reference counter itself and free the memory when there are no more references to the object. This is usually done by having an integer member variable in the object structure itself to hold the reference count. It can also be implemented with a separate structure for holding the reference counter, but it adds extra overhead as the reference counter must be searched for with each change.
The garbage collector, used to handle the scenarios where reference counting isn't enough, uses the following algorithm.
All of the steps, except 'clear counters' and 'verify unmarked objects' are incremental, i.e. they can be interrupted to allow the application and scripts to execute before continuing the garbage collection.
The application should ideally invoke the garbage collector every once in a while to make sure too much garbage isn't accumulated over long periods.
It may also be a good idea to do a complete run of the GC when it doesn't matter if the application pauses for a little while, for example when in menu mode.
Currently the garbage collector cannot handle application registered object types as it doesn't have enough knowledge of the internals of the objects to be able to follow all the references. It is therefore important that the application itself keeps track of application registered types that can form circular references. A future release will remedy this though.
By default AngelScript uses the memory heap accessed through the standard malloc and free global functions when allocating memory. Usually this means that AngelScript shares the memory heap with the application, though if the AngelScript library is compiled as a DLL or a shared object the heap may actually be separate from the application heap.
Some applications need extra control over the memory heap that the standard C/C++ library doesn't provide. This is common with video games for consoles, that have limited memory and cannot afford loosing space due to fragmentation or many small allocations. AngelScript aids these applications as well as it is possible to register custom memory allocation routines with the library, giving the application exact control over the memory used by AngelScript.