I think that there are misconceptions about the nature of timely GC in this thread.
* First I present some notes on how it could be achieved or approximated using incremental and generational techniques. * Second, I note that timely GC only exists in C++. On Fri, 2005-01-14 at 17:57 -0500, Michael Walter wrote: > You could change the GC scheme (*cough*) to use one similar to > Python's (ref-counting + additional GC for cyclic references > *double-cough*). You could adapt Java's last-generation GC scheme to do a really fast GC on scope-exit, only of objects created within that scope. However, this may require a relocating or treadmill GC to do efficiently. Otherwise, I seem to remember a zone-based GC strategy which allocated 'zones' to frames and GC'd by zone... will have to find a reference. It was very fast, since generally everything from a zone except the return value was garbage. Vague memories are also coming back to me about only being able to point from lower to higher numbered zones, except through gates ... I suspect the algorithm described at http://www-106.ibm.com/developerworks/java/library/j-jtp11253/ with card-marking on arenas would be applicable. PMCs could be relocated between arenas (promotion to an older generation?) could then store a redirect bit in the arena header of the old arena, and update all pointers on the next full GC (about 1 in 10 in the 1.4 hotspot JVM, except when thrashing). I note that in practice [and this is mis-documented] the hotspot JVM keeps separate permanent store, and appears to thrash on the object heap when permanent store is full, although this permanent store ought to be treated as a strictly older generation. This is all sparse thoughts upon which I will probably have to expand. > On Fri, 14 Jan 2005 14:40:43 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote: > > Hildo Biersma writes: > > You can't do refcounting selectively. It's all or none. > > > > Of course, in C++, you can, because you tell C++ which pointers are > > refcountable pointers at compile time. If, by static analysis, we could I thought C++ only guaranteed destruction (on return or exception) for objects which were directly on the stack. The idiom for guaranteeing lock-release on scope destruction is: void foo() { Lock foo(); /* critical section */ } Not void foo() { Lock *foo = new Lock(); /* not guaranteed destruction */ } which is being proposed as the Perl equivalent. Furthermore, I seem to recall comments throughout Perl's documentation stating that you could NOT assume that objects were GC'd on scope exit. > > tell Parrot when PMCs need refcounting before it assembled the bytecode, > > and also in some other places, we might be able to pull it off. But > > that's a halting problem problem if the language from which we're > > compiling is untyped. > > > > What I'd most like is to convince Larry to waive the timely destruction > > requirement. However, that doesn't really solve the problem for other > > languages that need timely destruction. Are there any? As noted above, I think only C++ guarantees it. Try the zone-based incremental-ish GC. Going to find some references. S.
