However, this is not always guaranteed. While Director's memory reclamation is often remarkably good, there are some cases it cannot cope with. In particular, if a list contains a reference to itself, the memory it occupies cannot be recovered:
-- pathological memory-leak example
-- note that this is specifically designed to devour a chunk of
-- Director's memory partition
-- in low memory conditions this
-- may cause your computer to hang, and even if it doesn't you
-- should certainly quit and restart Director after running it
on smallLeak
-- create a long list
set tempList = []
repeat with i = 1 to 10000
add tempList, i
end repeat
-- add a circular reference
add tempList, tempList
end smallLeak
on bigLeak
put "freebytes before = " & the freebytes set fb = the freebytes
-- throw away some memory a bunch of times
repeat with i = 1 to 50
smallLeak
end repeat
set fb = fb - the freebytes
put "freebytes after = " & the freebytes put "bytes lost = " & fb
end bigLeak
If you do actually run this example, check and purge the memory partition
in the "About Director" before and after doing so. Notice anything
worrying?
It isn't likely that you'll want to use such a blatantly circular data structure as the above, but even in less extreme cases circularity may arise if you're using complex structures. Since an ongoing memory leak can wreak havoc with the performance of your program, and may eventually cause a crash, it is important to be careful about cleaning up.
For most everyday purposes, however, lists can be left to dispose of themselves. If you know, for example, that your list only contains integers, there is no chance of self-reference and simply saying:
set myDisposableList = 0will dispose of it. Even this is only generally necessary in the case of global lists, which may otherwise persist indefinitely. Lists only used local to a particular handler should disappear when the handler completes. [ A method for aggressively disposing of lists and objects is discussed in section 14.10 ]