"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EFA1167.B4912224@chello.at...
> That certainly *is* welcome. Thinking is more important than coding.

The hardest part of a gc is making sure it works. I.e. the test suite for it is the most important piece. Subtle bugs in the gc can have a disastrous effect on D programs, making for very hard to pin down bugs. The \dmd\src\phobos\gc2\testgc.d is a good starting point.

I also suggest the "Garbage Collection" book on www.digitalmars.com/bibliography.html. It covers all the main algorithms, their variants, and strengths and weaknesses. It's essential reading, if you don't want to reinvent the wheel <g>.

What I see as ideal for D is a two-generation, partially copying collector, with write barriers on the old generation done in hardware with the paging system.

Walter wrote:
> 
> "Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EFA1167.B4912224@chello.at...
> > That certainly *is* welcome. Thinking is more important than coding.
> 
> The hardest part of a gc is making sure it works. I.e. the test suite for it is the most important piece. Subtle bugs in the gc can have a disastrous effect on D programs, making for very hard to pin down bugs. The \dmd\src\phobos\gc2\testgc.d is a good starting point.
> 
> I also suggest the "Garbage Collection" book on www.digitalmars.com/bibliography.html. It covers all the main algorithms, their variants, and strengths and weaknesses. It's essential reading, if you don't want to reinvent the wheel <g>.
> 
> What I see as ideal for D is a two-generation, partially copying collector, with write barriers on the old generation done in hardware with the paging system.

I've no set opinion on the algorithm that should be used. I know that most people that use malloc/free don't have a faint idea about the behaviour of the system they are using.

I agree that a testsuite must guarantee (as far as this is possible) the flawless operation of the GC system.

Given that, it would be nice to have an architecture that allows to plug
in different GC systems (e. g. by linking to different GC libraries) at will
and depending on the problem. Some user might need "hard real time GC"
while some other might prefer "copying GC to avoid fragmentation".

Pluggable GC might even be interesting to the GC scientists and might inspire them use D for some of their explorations.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

Walter wrote:
> I also suggest the "Garbage Collection" book on www.digitalmars.com/bibliography.html. It covers all the main algorithms, their variants, and strengths and weaknesses. It's essential reading, if you don't want to reinvent the wheel <g>.

I've just ordered the book. But usually I don't believe in the quality of prefabricated and published solutions.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

In article <bddfrm$a29$1@digitaldaemon.com>, Walter says...
>
>
>"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EFA1167.B4912224@chello.at...
>> That certainly *is* welcome. Thinking is more important than coding.
>
>The hardest part of a gc is making sure it works. I.e. the test suite for it is the most important piece. Subtle bugs in the gc can have a disastrous effect on D programs, making for very hard to pin down bugs. The \dmd\src\phobos\gc2\testgc.d is a good starting point.
>
>I also suggest the "Garbage Collection" book on www.digitalmars.com/bibliography.html. It covers all the main algorithms, their variants, and strengths and weaknesses. It's essential reading, if you don't want to reinvent the wheel <g>.
>
>What I see as ideal for D is a two-generation, partially copying collector, with write barriers on the old generation done in hardware with the paging system.

The GC does need information from the compiler about data types.
Some benafit can be gained from marking or allocating on a
separate heap data types that don't have any internal pointers
so that they don't need to be scanned.  Boehm has GC_malloc_atomic
for this purpose.

Any plugable GC architecture should contain information about the types being allocated.

> The GC does need information from the compiler about data types.
> Some benafit can be gained from marking or allocating on a
> separate heap data types that don't have any internal pointers
> so that they don't need to be scanned.  Boehm has GC_malloc_atomic
> for this purpose.
>
> Any plugable GC architecture should contain information about the types being allocated.

Agree. Conservative GC is a kludge to make GC work in environments that weren't really meant for it, but I see no point in making the task unnecessarily more complex (and less reliable :) in a language that is designed from ground up with GC in mind.

-fg

A interesting link :

http://www-106.ibm.com/developerworks/ibm/library/i-incrcomp/?ca=dgr-lnxw01TrashCompactor

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3EFAB36B.C0014A83@hls.via.at...
> Walter wrote:
> > I also suggest the "Garbage Collection" book on www.digitalmars.com/bibliography.html. It covers all the main
algorithms,
> > their variants, and strengths and weaknesses. It's essential reading, if
you
> > don't want to reinvent the wheel <g>.
> I've just ordered the book. But usually I don't believe in the quality of prefabricated and published solutions.

That book is better than most at being practical.

"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bdf2j3$1rui$1@digitaldaemon.com...
> The GC does need information from the compiler about data types.
> Some benafit can be gained from marking or allocating on a
> separate heap data types that don't have any internal pointers
> so that they don't need to be scanned.  Boehm has GC_malloc_atomic
> for this purpose.

Yes, that can help.

> Any plugable GC architecture should contain information about the types being allocated.

Juarez Rudsatz wrote:
> 
> A interesting link :
> 
> http://www-106.ibm.com/developerworks/ibm/library/i-incrcomp/?ca=dgr-lnxw01TrashCompactor

I've started a wiki page for the GC workgroup:
   <http://www.wikiservice.at/wiki4d/wiki.cgi?GCW>
and added your link.

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

It seems what is needed is something like:

In the typeinfo for every type there should be a function,    bool ScanObjectForPointer(void* object, void* p);   which could be used by the GC to scan blocks;  obviously it'd not be recursive thru pointers so we would also need   struct OPI { void* objptr; TypeInfo* type }  OPI[] GetNonNullPointersFromObject(void* object);    .. both functions would use the typeinfo size to determine the extent to scan.  Probably need something to scan arrays of objects as well..

If the compiler provided a framework like this, a non-conservative GC could be built off of it.

At very least some tables would have to be emitted with typeinfo* and offset and size for the members relevant to the GC.

Sean

"Fabian Giesen" <rygNO@SPAMgmx.net> wrote in message news:bdf77j$20sb$1@digitaldaemon.com...
> > The GC does need information from the compiler about data types.
> > Some benafit can be gained from marking or allocating on a
> > separate heap data types that don't have any internal pointers
> > so that they don't need to be scanned.  Boehm has GC_malloc_atomic
> > for this purpose.
> >
> > Any plugable GC architecture should contain information about the types being allocated.
>
> Agree. Conservative GC is a kludge to make GC work in environments that weren't really meant for it, but I see no point in making the task unnecessarily more complex (and less reliable :) in a language that is designed from ground up with GC in mind.
>
> -fg