Hey, After going through and hopefully learning the GC system yesterday, today I went through looking for problems in the code that uses it (or doesn't use it, as the case may be). Below are what I believe to be potential problems in Parrot's memory use. I may very well be mistaken on many of these, however.
Am I correct in assuming that the stacks stuff leaks memory? Both stacks.c and rxstacks.c allocate memory via mem_allocate_aligned, but never free it, relying on the GC for it (code written before the GC existed). Should these stacks be changed to use a buffers system, or should they be changed to free their own chunks on certain pops? Following the logic in register.c, which handles it's own memory of register stack chunks, I would guess the latter, although there might be a performance gain if it can reuse these chunks via the GC. I believe these are known, and the regex system is slated for a rewrite, but I'll mention these for completeness' sake. rx_allocate_info uses mem_sys_allocate, as does rx_clone_info. If those used buffers. Is that all that's needed to make GC and regexes work nice together? In addition, the regex handles its own allocation and deallocation for bitmaps, which it does for each 'oneof' match. Performance would surely improve if one could put these bitmaps into the pbc file somehow. Constant PMCs in the file would probably be needed here. Alternately, one could make the bitmaps GC-compliant, and just unreference them after the entire regex match is completed. Keys also allocate memory using mem_sys_allocate. Should this be changed over to Buffers at some point, or will this be internally-managed key memory? I'm guessing this is all WIP and likely to change completely, however. Each intqueue leaks some memory, as the new_container allocation is not freed. What's the policy on supporting these kind of non-core, but included in the distro, kind of things? Finally, I'd also argue for a renaming or #defining of mem_realloc to Parrot_reallocate, to match Parrot_allocate. At first glance, I thought mem_alloc punted down to the native realloc routines, and it was reallocing GC-managed memory. :) Hope this was helpful. If you can tell me which of the above I should ignore because it's going to get rewritten or is irrelevant, I think I can write the necessary patches. Mike Lambert
