Objects memory management in Delphi Web Script is automatic, and you never have to worry about releasing objects in a script if you don’t want to. However, there are elements of manual memory management in DWS which provide greater control, and allow to enforce correctness of object-lifetime.

For instance, in DWS you can avoid the issue that is present in traditional GC-based environments, where references to long obsolete objects can still live in memory, and can still be invoked without triggering exceptions.

Automatic Memory Management

Up to and including version 2.2, the garbage collection is implemented in DWS through reference-counting (based on Delphi’s interfaces), and supplemented by a special garbage collector which is responsible for handling and cleaning up object dependency cycles.

If you have no particular memory constraints or requirements, you can thus safely create objects in DWS and not worry about their release. The special cycles GC means DWS isn’t vulnerable like Delphi’s interfaces-based reference-counting is.

Manual destruction of objects

With DWS 2.2, destructors are being brought back in a meaningful way, i.e you can manually destroy an object that is still referenced, and the object will then acquire a special “destroyed” status. Any attempt to access a destroyed object’s fields, or invoke a destroyed object’s methods will trigger an exception.

Beyond controlled release, this mechanism can be used to make sure that an object, even if incorrectly kept around, can’t be used anymore without an exception happening.

Note that unlike in Delphi, to guarantee the correctness of the “destroyed” status, a destroyed object that is still referenced will still use some memory, for as long as it is referenced. However, that object’s Delphi-side objects and memory can have been freed, as well as the object’s memory used to store the object’s fields.

When debugging, it is possible to iterate over all script objects (via the program’s execution object), including all the “destroyed” objects which are being kept because of “dangling” references.

Cleanup of “leaked” objects

Objects that have not been manually destroyed, and are still referenced by the time EndProgram is executed will be cleaned up without having their destructor invoked. This covers the cases where the script execution has been completed (end of code reached), has been aborted Delphi-side, via an execution timeout, or terminated because of an unhandled exception.

The destructors are not invoked because when EndProgram is triggered, the script is no longer supposed to be running in a any way or form: the stack has been torn-down, and cross-object references become meaningless as the clean up forcibly proceeds.

For external objects exposed through TdwsUnit, you will get an OnCleanup event, which allows you to release your Delphi-side objects, though in OnCleanup you have to be aware that the script has already been terminated, so you shouldn’t Call script functions, or rely on other script objects still existing or being valid.