Usage of the garbage collection procedure, HEAP_GC, to clean up my heap variables.

Please, also see IDL's Automatic Garbage Collection technique introduced in IDL 8.0. You can find information about it in the IDL Help and in the Online IDL Documentation Center here:

http://www.harrisgeospatial.com/docs/Automatic_Garbage_Collec.html

Garbage collection is potentially a computationally expensive operation. Applications should be written to avoid losing pointer and object references and hence avoid the need for garbage collection.

Discussion
The HEAP_GC procedure causes IDL to hunt for all unreferenced heap variables and destroy them. It is important to understand that this is a potentially computationally expensive operation, and should not be relied on by programmers as a way to avoid writing careful code. Rather, the intent is to provide programmers with a debugging aid when attempting to track down heap variable leakage. In conjunction with the VERBOSE keyword, HEAP_GC makes it possible to determine when variables have leaked, and it provides some hint as to their origin.

General reference counting, the usual solution to such leaking, is too slow to be provided automatically by IDL, and careful programming can easily avoid this pitfall. Furthermore, implementing a reference counted data structure on top of IDL pointers is easy to do in those cases where it is useful, and such reference counting could take advantage of its domain specific knowledge to do the job much faster than the general case.

Another approach would be to write allocation and freeing routines layered on top of the PTR_NEW and PTR_FREE routines that keep track of all outstanding pointer allocations. Such routines might make use of pointers themselves to keep track of the allocated pointers. Such a facility could offer the ability to allocate pointers in named groups, and might provide a routine that frees all heap variables in a given group. Such an operation would be very efficient, and is easier than reference counting.