Miroslav Silovic <[EMAIL PROTECTED]> writes: > Leopold Toetsch wrote: > >>> I believe that you shouldn't litter (i.e. create an immediately >>> GCable object) on each function call - at least not without >>> generational collector specifically optimised to work with this. >> >> >> The problem isn't the object creation per se, but the sweep through >> the *whole object memory* to detect dead objects. It's of course true, >> that we don't need the return continuation PMC for the fib benchmark. > > Well, creation is also the problem if you crawl the entire free heap > before triggering the next GC round. You get a potential cache miss on > each creation and on each mark and on each destruction. To keep GC out > of the way, the entire arena has to be confined to cache size or less. > >> But a HLL translated fib would use Integer PMCs for calculations. > > Hmm, I'm nitpicking here, but it's not how e.g. Psyco works. It > specialises each function to specific argument types and recompiles for > each new argument type set. Assuming that you'll call only very few > functions with more than 1-2 type combinations, this is a good tradeoff. > It also removes a lot of consing, especially for arithmetics. > >> >>> ... This would entail the first generation that fits into the CPU >>> cache and copying out live objects from it. And this means copying GC >>> for Parrot, something that (IMHO) would be highly nontrivial to >>> retrofit. >> >> >> A copying GC isn't really hard to implement. And it has the additional >> benefit of providing better cache locality. Nontrivial to retrofit or >> not, we need a generational GC.
The catch with generation GC is that, once you have guaranteed destructors being called promptly, you still have to sweep the whole arena every time you leave a scope.
