> >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.
Perl strings, arrays, and hashes all require buffer manipulation, and will probably fall prey to this. I agree that I was probably generalizing a bit, and that in theory PMCs can criticalize their own methods. > >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. I said Dan gave a directive. I didn't say anyone listened to Dan, or implemented what he suggested. ;) > >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 Ah, but as internals designers, we don't need to worry about that. We get to push it into the compiler writers. Isn't it fun? :) I initially had the same opposition to Dan's idea that you have. I'm not sure why I eventually gave in...perhaps the lack of any other solution? Don't really recall. :) > 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. That's true. I believe most implementations have taken advantage of the ability to access the C stack, something we don't have the liberty of with our wide-reaching compatibility goals. I think this will be similar to the cost of a reference counting solution versus a tracing system, where the former amortizes the cost over the entire system, but ends up being slower in terms of total time used. Your approach would involve lots of computation in lots of little functions over parrot's execution, whereas Dan's would involve a full trace (equivalent to a DOD) to be performed every now and again. But that's just hypothetical posturing because I don't have any real benchmarks, of course. Mike Lambert
