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