Robin Redeker <[EMAIL PROTECTED]> wrote: > On Wed, Apr 27, 2005 at 02:27:58PM +0200, Leopold Toetsch wrote:
>> API's aren't finished yet and are extended more or less on demand. > Ah, ok :) Who will decide what is demanded? A patch on p6l is a good indication for a demand :) > Hm, ok, i guess i will try to port the language and environment i have > to parrot and see what i get. Fine. > Just for the curious me: What was the design decision behind the GC > solution? Was refcounting that bad? Refcounting gives a more global > speed hit indeed, but it's more deterministic and you wont run into > (probably) long halts during GC. (Java programs often suffer from this, > and it results in bad latency). Yep. Well there is one more issue besides speed: code complexity and correctness. Writing correct refcounting code is tedious and all extensions suffer from that problem too. Long halts can be avoided by either an incremental GC or by doing less work with an generational GC. None of the GC philosophies are faster per se it really depends on the implementaion. > You said, that most languages will have refcount semantics, just sounds > funny for me to implement a GC then. They have timely destruction semantics. I'm pretty sure that we can run generational GC as fast as a refcounting one. > Hm, that sounds not that bad if this works. Are there prototypes? Has > this been tried out? A very early and not yet functional generational GC is in src/gc_gms.c. It's lacking basically the interpreter support for scope enter/exit. > ... Sticking fresh objects into old ones > isn't that rare i guess (and also in my case it wont be that rare). Combined with: >> Note: "old" and "young" are terms of reachability in the object graph, It depends. Having everything in globals will hurt. But it's a bit too early to say more about that. >> mostly related to object creation time too (for subroutines) but not for >> more global-like objects. >> > How to combine generational garbage collection and timely destruction > there? Having a policy that doesn't check 'old' objects (often) wont > work for 'old' objects that need timely destruction. When objects are ordered according to their scopes, you basically have only to cleanup the top scope (or generation of objects). > So, are timely destruction objects in the younges generation all the time? No. But objects that need timely destruction can be put in front of their generation so that they are scanned first. > How to check whether this 'young' object, that need timely destruction, > isn't referenced by old ones? > Don't you have to go through all (even old) objects to determine whether > 'this' object that needs timely destruction, is referenced? Worst case yes. > I'm not an expert in garbage collectors, that are just some questions > that pop into my mind there. Maybe you can point me some paper or some > old discussion about this? I've no bookmarks, sorry. But google has them :) > robin leo
