www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A TODO for somebody: Full Reflection Gets You Smarter GC

reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Sorry, I don't have time to look into this in detail, but I'll post this 
idea so somebody else can explore it:

It is possible to have a smarter GC using compile-time reflection.  I 
haven't had time to explore the members-tuple feature (was it .members, 
or .membersof?), but if that tuple gives us both the offset into the 
type *and* the type of the member, then we can construct a GC which 
knows the types of certain allocations, and knows which elements in 
those allocations are pointers and which are other data.  At least, it 
can know this information in allocations where it knows the type.  In 
cases where it doesn't know the type, it can default to the old scheme 
(treat all possible pointers as pointers).

A thought.
Nov 20 2006
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Russ Lewis wrote:
 Sorry, I don't have time to look into this in detail, but I'll post this 
 idea so somebody else can explore it:
 
 It is possible to have a smarter GC using compile-time reflection.  I 
 haven't had time to explore the members-tuple feature (was it .members, 
 or .membersof?), but if that tuple gives us both the offset into the 
 type *and* the type of the member, then we can construct a GC which 
 knows the types of certain allocations, and knows which elements in 
 those allocations are pointers and which are other data.  At least, it 
 can know this information in allocations where it knows the type.  In 
 cases where it doesn't know the type, it can default to the old scheme 
 (treat all possible pointers as pointers).
 
 A thought.

I actually had the exact same idea this morning :). I've experimented a bit this afternoon trying to get type information using some templates but stopped when DMD kept crashing on me :(. [1] I have yet to find a syntax that'll get DMD to generate a compile-time array of structs. It seems the current tuples implementation is a bit... unstable. [1]: I'm not sure if someone's already added 'my' crashes to bugzilla, the search feature wasn't much help and I didn't have time to reduce them to small samples yet. Maybe tomorrow evening.
Nov 20 2006
prev sibling parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Mon, 20 Nov 2006 17:49:32 -0700, Russ Lewis
<spamhole-2001-07-16 deming-os.org> wrote:

It is possible to have a smarter GC using compile-time reflection.

I have a related idea that basically the programmer should be able to customise the garbage collection process for certain classes. For example, there is a method that can be used for getting doubly-linked list behaviour from a singly linked list. The idea is that an iterator holds pointers to two adjacent items in the list, and that the link item holds the xor of the pointers to the previous and next items. With this approach, it is always possible to do a step forwards or backwards. But there are no actual pointers to most of the items in the list - only those referenced by any current iterators and the first and last items (held as part of the list-as-a-whole object). You wouldn't use this data structure without some kind of custom allocators anyway, since saving that one pointers worth of space is pointless unless you also deal with heap allocation overheads, but depending on how you handle the custom allocation you may still rely on those links to indicate which custom-allocated blocks have still got valid items in them. And that suggests that you might want to inject something into the GC that can follow through the list step-by-step using the calculated pointers, ensuring that all currently used blocks get marked. A standard overridable method (in the list-as-a-whole class) would probably be able to do the trick. And the same approach could be used (in a few heavily instantiated or otherwise problematic classes) to restrict the part of the object that is checked for pointers. Theres probably an efficiency issue, though. -- Remove 'wants' and 'nospam' from e-mail.
Nov 24 2006