At 02:23 AM 5/20/2002 -0400, Mike Lambert wrote: >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. ;)
I'll think about debating it tomorrow. :) >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. I don't think this is accurate. People calling vtable methods have no need to mark themselves as critical. The things that mark themselves critical are internals that are allocating and holding onto objects. I think very few vtable methods even fall into this category, but I'd have to survey the .pmc files before continuing this discussion. > > 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. ;) I've seen no evidence of that hammering. I still think we are having GC crashes on this issue. >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. Yes they do, they have to call an explicit routine, clear_uncollectable >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. :) I'd just like to see someone implement a solution, and give benchmarks to back it up. I'd like to see both approaches compared, personally, and I think neither requires a whole lot of thought to implement. I also think we should reference existing research and implementations, since we aren't the first to do this. -Melvin
