Memory Management
From Xojo Documentation
With object-oriented programming, each new object you create takes up space in memory. Xojo uses a technique called Automatic Reference Counting (ARC) to manage the memory used by objects. ARC is faster and more efficient than other memory management techniques such as garbage collection.
Here is how it works: When you create a new instance of a class (an object), an internal reference counter for the class is increased. When the class goes out of scope, the reference is decreased. When the reference reaches 0, the class instance is immediately removed from memory.
This means that instances of classes are removed from memory automatically when they are no longer used. Suppose you create a class based on a ListBox. You then create an instance of that class in a window. When the window is opened, the instance of the class is created in memory automatically. When the window is closed, the instance of the class is automatically removed from memory. If you store the reference to a class in a local variable, when the method or event handler is finished executing, the instance of the class is removed from memory. If you store a reference to an instance of a class in a property, the instance will be removed from memory when the object owning the property is removed from memory.
ARC really is a great way to handle object memory management and is also used by languages such a Swift and Objective-C. With ARC you generally don't have to worry about memory management except for the special case of circular references. In those cases, you'll need to manually release an object (by setting it to Nil) so that its reference count decreases to allow it to eventually reach 0, thus allowing it to get removed from memory. Otherwise, your app will create an object that is never released from memory, causing what is called a memory leak in your app. This special case does not occur often, but when it does you can make use of Weak References to help mitigate it.
More About Memory Leaks
Memory leaks occur when objects are created but never destroyed. As more and more objects are created and not destroyed, the amount of memory used increases. Eventually, the app will crash because the computer runs out of available memory. In a desktop app this may not be a big deal because desktop and laptop computers typically have lots of memory and the user will eventually quit the app, clearing its memory. Mobile apps also should pay attention to memory leaks because mobiles devices do not typically have as much available memory as desktop computers and can run out of memory sooner.
Memory leaks are more serious in web apps because the web app may be running for days, months or even longer. If your app is running as a CGI, once the number of users (sessions) accessing the app gets to zero, the app will quit and this will release any memory that app is using. However, your app may never reach the point where there are no users so you need to be careful about not leaking memory. And standalone apps generally do not quit.
The first thing to do is to look for circular references in your code. That is, object a has a reference to object b and object b has a reference to object a. When it comes time to call destructors to release memory, neither one can be called because their reference counts cannot reach 0.
Refer to Web App Optimization to learn more about how to effectively manage memory in your web apps.