> I would like an elegant, easy to use solution for making the GC > play nicely.
So would we all. :) > This creates a sliding scope window that GC must not peep through, > and provides a clean interface for internals writers. I think you've explained this idea before, but I complained about it because I thought that the bottom_gen never got set to top_gen, and figured a lot of stuff would end up permanently allocated. Now that I see how it works, it seems to make a lot of sense. Problems with your approach: GC-sensitive functions must remember to mark themselves as critical. This will be a source of bugs (whether that's a big enough of a complaint is up for debate. ;) Most vtable methods, and/or people that call vtable methods, will end up making themselves critical. This overhead will be imposed on most function calls, etc. Lots of the string api will require the users to mark themselves as critical. > Lets hammer this one design issue out for good because I'm tired of worrying > about it and I think its hindering current Parrot developers and > confusing potential newcomers. > If it is not what I propose, lets at least discuss alternatives. If I remember correctly, this did get hammered out with a directive from Dan. ;) His approach was: the live flag is valid only within GC. all newly-allocated headers are marked as uncollectable there is a clear-uncollectable op, which iterates over the headers, and marks them all as collectable Basically, you need to have assigned all your headers to something traceable by the root set before your current op ends. The advantages of this are that nobody needs to worry about the GC implications of their code. The disadvantage are: - very expensive ops can allocate lots of uncollectable headers? - you must explicitly allow for marking headers as collectable in your opcode, at strategically placed locations. otherwise, nothing gets collected and you have no dod results, although collection will still occur normally. Any other contenders to the ring? Anyone have any other major dis/advantages they'd like to contribute about the above approaches? FWIW, I feel confident enough about my understanding of Dan's idea to implement that, should we choose it. Melvin's idea would require that much more work on the multitude of functions, and so I can't imagine it being as easy to implement. :) Mike Lambert
