On Fri, Dec 4, 2009 at 11:00 AM, Kevin Tew <[email protected]> wrote: > Coding policy based intergenerational management will be violated (creating > GC bugs) by adding new features and refactoring old code. > > Unless I'm missing something obvious this seems likely to multiply the types > of bugs that constant PMCS introduce.
Let me try and explain better what I am thinking: We'll have at least two functions to allocate a new PMC header: Parrot_new_normal_pmc and Parrot_new_immortal_pmc. On any field access we'll have a write barrier setup that can identify the generation of the child PMC, and if the generation of the child is the same as the generation of the parent, we don't need to update the intergenerational list. We only need to update the intergenerational pointer list when a pointer is "intergenerational". So if we call Parrot_new_immortal_pmc() to create the parent, and we call it again to create the child, we've manually shown the relationship that the two are in the same generation and we don't need integenerational pointers. However, if the parent is immortal and the child is normal, the write barrier will detect that and add the intergenerational pointer record. We could detect the mortal/immortal status of a PMC by checking a flag. So there would be no manual modifications to the intergenerational pointer list, and there would be fewer bugs because the differences would be detected automatically (currently, differences aren't detected or accounted for at all, hence all the bugs). We can all keep in mind that this is an optimization, something that we should be able to apply after we've created the generational GC and after we've inserted write barriers in all the proper places. There are lots of similar optimizations we could try once we have a good base system in place. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
