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

Reply via email to