• Russ Lewis (12/12) Nov 20 2006 Sorry, I don't have time to look into this in detail, but I'll post this...
• Frits van Bommel (10/24) Nov 20 2006 I actually had the exact same idea this morning :). I've experimented a
• Steve Horne (29/30) Nov 24 2006 I have a related idea that basically the programmer should be able to

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.

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.

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.