> Add a counter to the interpreter structure, which is incremented every > opcode (field size would not be particularly important) > Store this counter value in every new object created, and set the 'new > object' flag (by doing this on every object, we remove the requirement for > the creating function to be aware of what is happening) > If an object is encountered during DOD that claims to be new, but was not > created during the current opcode, dispute the claim. > If the counter has exactly wrapped in the meantime, an object might survive > longer than it should.
I know Dan's proposed solution has already been committed, but I'd like to add my support for this. In addition to providing a counter per opcode to ensure that we don't prematurely GC data, this field could also be reused to calculate the generation of a particular buffer, to help sort it into a correct generational pool (if/when we do get that). Another proposal is to walk the C stack. In runops (or some similar high-level function) we implement a dummy variable, and store a reference to it in the interpreter. In do_dod, we create another dummy stack variable. We then walk the memory byte by byte (or maybe some larger amount, if that's guaranteed), check to see if it passses 'the three rules', and then mark the buffer it points to. This is on the conservative side in that we might accidentally mark things we shouldn't. Then again, with our registers, it's very possible to reference old data which the program never bothered to clear, which also would be overly conservative. The three rules were: (as defined in Jones and Lins' Garbage Collection, pg 233) - Does p refer to a heap? (Is it within the low and high marks of all the header pools) - Has the heap block been allocated? (Go through the heaps, and check to ensure that this pointer points into one of our header blocks) - Is the offset a multiple of the object size of that block? (So we don't get random memory pointers into the header list, but only aligned ones) As long as the C stack is guaranteed to be contiguous, this should be portable. I'm not sure if that is guaranteed by ANSI C, however. Has this already been considered and explicitly rejected? Thanks, Mike Lambert
