A few problems have come up lately dealing with the mess that is src/gc/system.c (formerly src/cpu_dep.c). This is the file that handles the system-dependent parts of the GC mark phase. This is where the processor registers are stored on the stack and the stack is walked to extract pointers to PObjs for marking.
There are a number of interesting things in this file, and I've blogged about some of them in the past when I was doing my GC work over the summer. One interesting part, which is turning out to be causing build problems now, is the way the processor registers are retrieved on SPARC systems. Current implementation is to use hand-assembled machine code words, put them into a manually-aligned array on the stack, and execute it. Just imagine all the things that could go wrong with that! Infinoid++ sent me this link that explains how Sparc works in more detail. Fun read!
I've also been looking closely at the Boehm-Demers-Weiser collector. It isn't going to be quite as simple as a direct drop-in replacement for malloc in Parrot, I would need to create a dummy GC core to handle some of the expected bookkeeping, but it's something I definitely want to try out in the next few days. I'm also not sure if I'd be able to tune it to handle timely destruction, but it's worth a shot.
