Sounds like this stuff will collide violently with my local changes. I'm trying to track down a nasty memory corruption bug. It sounds like it would probably be easier to find with your new version, though.
The only real changes of interest I have so far are to finish the implementation of new_tracked_header, export the mark_used() function for use by custom mark() vtable entries, and change a couple of types to eliminate a dozen typecasts or so. All of which I'm happy to re-apply to your version, but I guess I'm voting for your patch to be applied sooner rather than later so I can re-instrument the code and hunt this corruption bug down. I suspect the "bug" may be in my understanding of the memory management API, though. If I want to maintain a linked-list of my own objects, how do I do it? If I carve out my objects (hash buckets) from a Buffer, then GC would keep moving them around and breaking the ->next link pointers. Setting the immobile flag doesn't seem to do it, probably for the same reason that the GC PDD says "don't set this on Parrot_allocated memory". I guess if there were a way of registering a callback for when the memory gets moved, I could use that to fix things up, but that would bloat up the Buffers. For now, is it the case that if you want to store pointers in memory, you have to use mem_sys_allocate() for anything pointed to? Btw, this is only a weak guess about what's going on, because the corruption I'm seeing isn't even in the linked list nodes. It only happens with GC_DEBUG, but it's not an infant mortality bug. Argh.
