> For (1), maybe we should add an opcode: get_number_of_live_objects? > Then you could write a test case that records the number of live > objects, does stuff, forces a sweep and collect, and checks that the > saved number + #expected live objects is equal to the currently live > number?
I agree this kind of testing is needed. It doesn't cause parrot to crash and burn like other bugs do, but it's still just as bad in the long run. The problem is that currently, these types of tests are not doable via opcodes. There was some talk about allowing for C-programs to participate in the test suite as part of the make process awhile ago, but nothing came of it. There are lots of things we aren't testing, and making opcodes for every possible thing so we can test them is going to be painful (sprintf, for example...opcodes can't take a variable number of arguments.) > For (2), a compile option that scribbles 010101010101... all over > collected objects? It's not perfect, but it would make it quite a bit > less likely for mistakes to slip by. This isn't any better, I don't think. The fundamental problem is that we want to avoid read OR writes to memory that's not available for use. The above proposal would eliminate most reads that were using pointers. If I request memory, do something which gets it collected, then initialize my requested memory, the above apprach will not help. I'm not sure if there's any 100% effective solution to catching these bugs. It might be useful to punt header allocations down to mem_sys_allocate when GC_DEBUG is turned on, with the hope that memory won't get reused nearly as often. DOD runs would still be performed (the pools would have to store pointers to the memory we've allocated), and DODing of a header would cause it to be zeroed (or 0101010'ed) out, and then mem_sys_free'd. But yours is certainly much easier and safer to implement. :) Mike Lambert
