www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Food for thought

reply pragma <pragma_member pathlink.com> writes:
For reasons unexplained, my mind was wandering and ran into the concept of D
eventually having a compacting GC.  I thought for a bit as to what it would take
to implement this.

Since D doesn't have the luxry of a managed environment (we're on bare metal
here and not some VM), the GC cannot go around willy-nilly moving pointers all
over the place.  This is most evident with anything that uses pointers.

References, on the other hand, are accepted to be D specific and presently are
required to be explicitly cast to a pointer (unless I'm mistaken).  Could we
take advantage of this?  What if each reference was in fact a pointer to an
entry within a registry of movable/compactable chunks of memory?  The act of
casting a reference to a pointer would expose the actual memory location, while
all other reference-to-reference assignments would simply move the defrenced
entry.

The GC could also expose pin/unpin methods to keep things from moving while a
typical pointer is outstanding for a mobile piece of memory.  Separate memory
pools could also be used to avoid compacting altogether.

All-in-all, the result would be something not unlike a "Smart-Pointer" in C++
with all the pros and cons implied (dereferencing to the actual piece of memory
being a big consequence).


- Pragma
[[ Eric Anderton at (do not look at reference with remaining eye) yahoo dot com
]]
Sep 21 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
pragma wrote:

 For reasons unexplained, my mind was wandering and ran into the concept of
 D
 eventually having a compacting GC.  I thought for a bit as to what it
 would take to implement this.
 
 Since D doesn't have the luxry of a managed environment (we're on bare
 metal here and not some VM), the GC cannot go around willy-nilly moving
 pointers all
 over the place.  This is most evident with anything that uses pointers.
 
 References, on the other hand, are accepted to be D specific and presently
 are
 required to be explicitly cast to a pointer (unless I'm mistaken).  
Actually I think Object can be implicitly cast to void*
 Could
 we
 take advantage of this?  What if each reference was in fact a pointer to
 an
 entry within a registry of movable/compactable chunks of memory?  The act
 of casting a reference to a pointer would expose the actual memory
 location, while all other reference-to-reference assignments would simply
 move the defrenced entry.
That sounds like a handle. It would be interesting to look in phobos (or user code) to see how often an object is cast to a pointer - even void*. Probably a bunch.
 The GC could also expose pin/unpin methods to keep things from moving
 while a
 typical pointer is outstanding for a mobile piece of memory.  Separate
 memory pools could also be used to avoid compacting altogether.
More likely I expect D will eventually use a mostly-copying collector if it has any copying at all: http://www.memorymanagement.org/glossary/m.html#mostly-copying.garbage.collection
 All-in-all, the result would be something not unlike a "Smart-Pointer" in
 C++ with all the pros and cons implied (dereferencing to the actual piece
 of memory being a big consequence).
 
 
 - Pragma
 [[ Eric Anderton at (do not look at reference with remaining eye) yahoo
 [[ dot com ]]
Sep 21 2004
parent pragma <pragma_member pathlink.com> writes:
In article <ciqj1q$90l$1 digitaldaemon.com>, Ben Hinkle says...
pragma wrote:
 What if each reference was in fact a pointer to
 an
 entry within a registry of movable/compactable chunks of memory?  The act
 of casting a reference to a pointer would expose the actual memory
 location, while all other reference-to-reference assignments would simply
 move the defrenced entry.
That sounds like a handle. It would be interesting to look in phobos (or user code) to see how often an object is cast to a pointer - even void*. Probably a bunch.
Thank you... "handle" was the word I was looking for, but it seemed to escape me as I sat down to type. And yea, I wonder if the present layout of phobos would be good for this kind of GC design. Too many casts to void* would really kill performance on top of an already expensive (potentially, barring any compiler optimization) solution. I guess this is what the "unsafe" blocks in Managed C++ are for after all, eh?
 The GC could also expose pin/unpin methods to keep things from moving
 while a
 typical pointer is outstanding for a mobile piece of memory.  Separate
 memory pools could also be used to avoid compacting altogether.
More likely I expect D will eventually use a mostly-copying collector if it has any copying at all: http://www.memorymanagement.org/glossary/m.html#mostly-copying.garbage.collection
Gotcha. So the GC would simply look to distinguish between reference types (ambigiuous or not) and act accordingly? I guess that rather than try to manage all the possible reference types as we go (as proposed here), the alternative is to deduce them as we go... sounds like that could cause a collection cycle to get out of hand real quick. - Pragma
Sep 22 2004