Unknown writes: > 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.
There are a lot of partial solutions. I get the impression that when they say "timely destruction" they want a full solution. Here's an example of a case that most partial solutions won't catch: my %data; sub a { open my $fh, ">somefile"; $data{fh} = $fh; } sub b { %data = (); } a(); # ... b(); > I thought C++ only guaranteed destruction (on return or exception) for > objects which were directly on the stack. That's true, you have to explicitly delete most memory. I was actually referring to the template refcounting classes that I use all the time: void foo() { ref<Image> image = new Image("somefile.jpg"); image->draw(); // image will be cleaned up automatically } Here, C++ manages only to refcount objects (or rather, pointers) that are declared using ref<> instead of *. In a dynamically typed VM this isn't possible. Luke