Hope no one minds me essentially reposting this email. :) > 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).
There was a frame stack patch that fixed a similar problem awhile back, but the above problem still seems to be there for (rx)stacks.c. Probably should just be a simlar patch that causes it to not free memory. > 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? Ping. This should probably return a Buffer, and store it in a PMC called RxAllocInfo that has the buffer_pointer set. This would be done in rx_allocate_info and rx_cloneinfo. > 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. This is more longterm, and would require a .pbc file change most likely. I won't touch this one. :) > 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. This is still a horrible memory mess. Mixed usage of mem_sys_* functions and direct native versions. No use of Buffers, and lots of native allocing for small structs. I could probably attempt this, but I'll need to take the time to learn the current keyed system befoer I try anything. > 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? A patch is easy to make. But the question of policy still remains? > 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. :) Dan said it was a good idea, so I could write up a patch. Not sure how that'll conflict with the GC/mem changes he is making, but has not yet applied. > 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. I'll reiterate the above statement. I'm happy to write patches, but I'm not sure if I should. Is it worth bothering with the regex stuff? Or intqueue? Or should I wait awhile until Dan checks in whatever revisions he's made? Mike Lambert
