1. Immediate reclamation can be part of an interface to the resource instead of performed in the finalization step, so that's not necessarily a ref-counting advantage.
2. "A Pure Reference Counting Garbage Collector", ie. one that can even collect cycles without an additional GC: http://citeseer.ist.psu.edu/539023.html 3. From prior discussions, it seems to me that Neko doesn't want reference counting because one of its primary purposes is direct interfacing and easy interoperability with C. The Boehm conservative GC is thus the only viable choice I know of at the moment. Sandro On 8/20/07, Matt Campbell <[EMAIL PROTECTED]> wrote: > What challenges would be involved in modifying Neko to use reference > counting instead of or in addition to GC? Could it be done without > modifying the C FFI? I suppose that the use of setjmp/longjmp for error > handling would pose a significant challenge, though if reference > counting is used in conjunction with GC, then a possible compromise > would be to let GC reclaim no-longer-used resources when an error occurs. > > I am aware that the merits of reference counting versus GC have been > debated for years (decades?), and GC seems to have prevailed. I amalso > aware that the classic problem with reference counting is inability to > detect reference cycles. However, reference counting has the advantage > (undisputed, AFAIK) that in the normal case, resources are reclaimed as > soon as they're no longer used. I don't care much about memory here; > I'm more concerned about open files, COM objects (I know there is no COM > library for Neko yet), and the like. So my preference would be a VM > that does both reference counting and GC, as the C implementation of > Python does. > > Thoughts? > > Matt > > -- > Neko : One VM to run them all > (http://nekovm.org) > -- Neko : One VM to run them all (http://nekovm.org)
