Re: GC strategies

Date view Thread view Subject view Author view

From: Tim Wilkinson (tim@transvirtual.com)
Date: Sun Nov 01 1998 - 15:20:39 EST


Archie,

You could "fix" the server problem by running a low priority thread in our
server which periodically invoked the GC by hand - not too elegant of
course but it might help yoiu.

But regarding the incremental GC - really the GC should just be thrown
away and replace by something whihc is a bit more state of the art -
something generational would be my choice (generational and incremental is
also posibe though some of the literature doesn't seem to think this is a
good idea).

Perhaps someone shold look into adapting a public domain GC for Kaffe -
there are a few out there. Of maybe we should just bite th bullet and
rewrite the thing.

Cheers
Tim

On Sun, 1 Nov 1998, Archie Cobbs wrote:

> Godmar & Alexandre-
>
> Thanks very much for the comments on reference counting.. that's
> exactly what I was looking for. E.g., the problems with synchronization
> and locality didn't occur to me. I can see how they would slow
> things up a great deal...
>
> So, on to the next idea :-) that is, getting the incremental
> GC working. What's left to be done? Is it more missing implementation
> or debugging what's there? Any subtle points I should be aware
> of looking through the code?
>
> Just as a data point, here's my motivation for asking about this
> stuff... one of my applications is a server that accepts transaction
> connections from clients. So it spends a lot of time just sitting
> there doing nothing. The non-optimal behavior is..
>
> - The GC usually gets triggered during a client transaction
> (because that's when new memory is needed), so clients often
> experience a noticable pause.
>
> - While no clients are connected, all the unreachable objects
> are still held by the server indefinitely, which means it's
> holding a lot of memory that the rest of the system could be
> using.
>
> - It's a shame that while the server is just sitting there it
> can't be cleaning up memory ahead of time.
>
> I'm sure this is a typical scenario.
>
> Thanks,
> -Archie
>
> ___________________________________________________________________________
> Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
>


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:02 EDT