gregtour
commented
9 years ago After attempting reference counting multiple times without success, either because of duplicated references, references that weren't being counted, or trying to invalidate valid data, I decided to use a trace garbage collector for Duck's memory management solution. Right now, the manager tracks all dynamic objects and the interpreter is stopped frequently to identify all objects which are outside the scope of the running program. These resources are then freed.
Some performance issues may still exist, with the requirement of stopping the world to run an iteration of garbage collection, and the current garbage collector using a set of vectors to enumerate resources rather than something more efficient like a heap, tree, or hash table. There may also be a few issues with edge cases that have not been resolved yet as well.
Currently, all parameter and variable usage results in a record being stored in the context of the corresponding scope of the program's execution. There is no reference counting or tracking of the variable to determine when it should be freed. This is not a memory leak because all allocations are tracked through ALLOCATE on a growing list of memory pages and freed when the interpreted script has halted, however it can lead to errors and undefined behavior when the system runs out of memory.
This issue should be fixed by designing and implementing a memory management system that uses garbage collection to keep track of variables, objects and references, as well as function closures that are created over the scope of the program's execution. Hopefully, this scheme will be able to maintain good performance and avoid the pitfalls of memory fragmentation.