On Wed, Apr 27, 2005 at 02:27:58PM +0200, Leopold Toetsch wrote: > Robin Redeker <[EMAIL PROTECTED]> wrote: [...] > > Any hints when looking for functions that 'maybe' go into the API? > > API's aren't finished yet and are extended more or less on demand. >
Ah, ok :) Who will decide what is demanded? > > Well, what happens if some objects are not seen at the beginning, but > > very late in the run? Does that mean, i maybe have to wait 100ms (or > > longer, don't have any idea how long it may take) or such if i have around > > 1*10^3 - 1*10^5 objects that need timely destruction? > > > And does that mean, the time spend in GC is very indeterministic? > > It really depends, but worst case can be a full GC run through all > objects with O(n) performance. But the worst case can usually be avoided > by good coding paractice. Hm, ok, i guess i will try to port the language and environment i have to parrot and see what i get. 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). You said, that most languages will have refcount semantics, just sounds funny for me to implement a GC then. > > We'll have a generational garbage collector eventually, where one > generation is one scope that needs timely destruction. We can have > counts of active objects per generation. The "all seen" is then usually > achived by scavenging just the youngest generation on scope exit, *if* > the numbers of the old generation are still valid. Hm, that sounds not that bad if this works. Are there prototypes? Has this been tried out? > > But there is of course the possibility of inter-generational stores. If > your code sticks a freshly created object into a rather old one, > live-ness of the object is determined by the old objects. If the > overwritten object needs timely destruction too, it's not know, if the > last reference to it is gone or not. Well, whats the solution here then? Sticking fresh objects into old ones isn't that rare i guess (and also in my case it wont be that rare). > > Note: "old" and "young" are terms of reachability in the object graph, > 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. So, are timely destruction objects in the younges generation all the time? 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? 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? robin -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker
