Robin Redeker <[EMAIL PROTECTED]> wrote: > On Wed, Apr 27, 2005 at 08:09:48AM +0200, Leopold Toetsch wrote:
>> albeit it isn't part of the official embedding API (yet). > Ok, thanks, i'll have a look at that. > Any idea when there will be a more complete official embedding API? > 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. >> This will eventually be replaced by: >> >> enter_scope 0 | 1 # NEEDS_TIMELY_DESTRUCTION >> exit_scope > Does this mean, i have to know whether this subroutine handles objects > that need timely destruction? Normally you don't know it in the general case. So the default for languages with timely destruction semantics would be to emit "enter_scope 1" except the compiler (or an optimization hint) can deduce that the scope wouldn't need timely destruction. > 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. 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. 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. 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. > cu, > robin leo
