Re: Aliasing and Garbage Collection

[Richard Beton <richard.beton@xxxxxxxxxx>]

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

begin:vcard 
n:Beton;Richard
tel;pager:ICQ: 56840977
tel;cell:MSN/Hotmail: richardbeton@xxxxxxxxxxx
tel;fax:01794 833434
tel;work:01794 833458
x-mozilla-html:TRUE
url:http://www.beton.freeserve.co.uk/
org:Roke Manor Research Limited;Internet Technology & Networks
adr:;;Roke Manor: http://www.roke.co.uk/;;;SO51 0ZN;UK
version:2.1
email;internet:richard.beton@xxxxxxxxxx
title:Internet Consultant
note;quoted-printable:The information contained in this e-mail is confidential and must =0D=0Anot be passed to any third party without permission. This =0D=0Acommunication is for information only and shall not create =0D=0Aor change any contractual relationship. =0D=0A
fn:Rick Beton
end:vcard