Debugging GC Problems (in Parrot)

by chromatic

Memory problems can be difficult to find and fix. I'm a huge fan of Valgrind, but it only works at the C level. The Parrot virtual machine allocates memory with malloc and releases it with free in a few places, and Valgrind is indispensable for making sure that those match.

Unfortunately for Valgrind, Parrot provides garbage collection, and two of its fundamental data structures rely on the correctness of the garbage collector. Some of the weirdest, and most difficult bugs to solve within Parrot are bugs in our implementation of garbage collection, usually where active objects get collected too soon.

Memory problems are often very unportable. Not only can one program demonstrate a problem where hundreds of other programs run without problems, but one operating system differs from another. Perhaps 64-bit platforms work just fine, but 32-bit platforms have a nasty segfault. Maybe the particulars of how you compiled the program may change memory layout sufficiently to avoid the problem.

Debugging GC-related problems reported on that one platform you don't have access to is time-consuming and difficult. I discovered another way recently. Now reproducing GC problems in Parrot is possible across platforms, making them much easier to diagnose--and once you can diagnose a problem, you've done most of the work to fix them.


Ralph Corderoy
2007-11-01 05:16:35
"rather than calling malloc to ask the operating system to find enough free memory"

malloc() often doesn't need to talk to the OS, it just returns some unallocated memory it already had to hand.

2007-11-01 15:57:17
@Ralph, that's true. I didn't want to go into too much detail about virtual memory and fragmentation, but perhaps I should have left the subject a sentence earlier.