Since Onyx includes an automatic mark and sweep garbage collector, memory management typically requires little thought. There is no risk of leaking memory in such a way that it cannot be freed. However, it is possible to consume large amounts of memory by creating objects, then keeping references to them long after they have outlived their usefulness.
Onyx objects fall into two categories according to type: simple and composite. Simple objects take up no virtual memory of their own; they are embedded into other composite objects. For example, an integer on the operand stack takes up only the space that the stack requires to store it. The same is true of an integer that is stored as an element of an array. Composite objects are composed of references that fit into the same places that an integer is stored, plus additional structures stored elsewhere in virtual memory. There can be multiple references to the same composite object, and as there is a chain of references that makes it possible to reach a composite object, the garbage collector will leave it alone.
It is usually pretty obvious how to remove references to objects. Objects on the operand stack can be popped off. Definitions in the dictionary stack can be undefined. However, there may be situations such an array that contains references to various objects, and the array cannot be discarded as a whole, but individual elements are no longer needed. The null type is useful for clobbering such references, and can even be effectively used to clobber portions of procedures, since when a null object is executed it does absolutely nothing. This unique aspect of null objects may not seem significant, but consider that all other objects, when executed, are either pushed onto the execution stack and executed, or pushed onto the operand stack. Doing nothing at all can be useful.