From: Richard Beton (richard.beton_at_email.domain.hidden)
Date: 2000-10-17 11:39:40
Tom Locke wrote:
> I am a bit concerned (and hoping that I've misunderstood) by the suggestion
> that the overhead of GC can also be removed by simply 'buying twice as much
> memory', and not reclaiming anything. In a program with lots of dynamic
> allocation, i.e. most programs, especially OO, memory would be leaked very
> rapidly, I would imagine most Java code could get through a megabyte in a
> matter of seconds. It might work if you buy a million times as much memory!
Yeah, I have to say: this point was lost on me too. Is there some theoretical
result that shows that all you need is 2 * m, where m is your original memory
size. (...and does this doubling apply ad infinitum... only joking ;-)
> Many programs use graph data structures. It's very nice to know that nodes
> that are cut off from the graph are somebody elses problem (i.e.
> automatically deleted). In the nameless language that I'm working on, the
> overall system is free from aliasing and needs no GC, but I'd like to
> provide a 'graph' as a standard container, every item in the graph has an
> ID, and can contain the ID of other items, the only way to retrieve an
> object from the graph is using its ID, and items are automatically removed
> when all copies of the ID are lost. For ID read pointer and you've
> effectively got a separate address space with it's own GC. The important
> point is that it more managable beacuse the ID's are only valid inside their
> own graph.
This is a similar concept to the memory pool. Each memory pool is a reserved
area of memory. Functions are provided to create data structures within the pool
as required. At a certain point later in program execution, the entire pool is
destroyed. This saves the effort of freeing individual structures from within
the pool.
I guess that memory pools could either be fixed in size or be dynamically
growing, according to implementation.
A good example of pool use is within the Apache webserver: pools are created for
each client connection. Cleanup at the end of each HTTP request is easy.
Sorry, Tom, if this is teaching the sucking of eggs! You probably know all this
already.
Regards
Rick
[ Part 2, "Card for Richard Beton" Text/X-VCARD (Name: ]
[ "richard.beton.vcf") 16 lines. ]
[ Unable to print this part. ]
This archive was generated by hypermail 2.1.7 on 2004-10-31 20:03:55 GMT
© Copyright WoTUG
All rights reserved