[boost] prox_descriptor feedback?

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2003-01-21 15:44:53

Philippe: I just wanted to let you know I am looking at your code at:

http://groups.yahoo.com/group/boost/files/gc_ptr.zip

However, I've not had time to understand it fully.  I do like the way
you've got a virtual table pointer (VTP) installed in each garbage
collected object.

Currently, I'm trying to document my stuff with UML and possibly some
pattern-like description of all the classes; however, it's taking a
long time.

One reason I'm interested in the installed VTP is that it could have a
slot for returning the:

  
&boost::mem_mgmt::mk_internal_pointers_descriptor_of<T>::the_ip_descriptor()

as shown in the

http://groups.yahoo.com/group/boost/files/shared_cyclic_ptr/gc.hpp

As noted in the comments at the top, this was modified from code by
Mirek Fidler which he posted to comp.lang.c++.moderated with:

From: "Mirek Fidler" <cxl_at_[hidden]>
Subject: OGC++: Optional Non-Conservative Garbage Collector for C++: 
Library solution - possible breakthrough
Date: 18 Oct 2002 18:34:09 -0400

What are the gotcha's in adding a pointer to the_ip_descriptor as part
of the gc_header in your gc_ptr.hpp?

Mirek: The modifications shown in gc_ptr.hpp together with further
modifications (i.e. the unshared_ptr) proposed in my previous boost
post:

Subject: Re: Shared_ptr "mini garbage collector"
Date: Tue, 07 Jan 2003 19:55:58 -0600

should solve the problem mentioned by Hans Boehm and which you
repeated to me in your email with:

Subject: Re: my additional gc.h comments
Date: Mon, 18 Nov 2002 16:42:09 +0100

To be more specific, the code in:

http://groups.yahoo.com/group/boost/files/shared_cyclic_ptr/main.cpp

demonstrates how uncollected and collected objects can be handled:
simply use separate descriptors for different types of proxies to be
scanned.  The descriptor:

  prox_recorder::the_singleton().m_descriptor[non_collect]

is for proxies (smart pointers) containing subjects that are just
scanned (like those allocated with BW GC_malloc_uncollectable
function) [ see
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gch.txt ] and
the yes_collect would be like those created with the BW normal
allocator (GC_malloc).  The other type of allocator in BW is
GC_malloc_atomic, which corresponds to the non_scannable type, i.e. in
main.cpp the proxy with CollectPolicy =

  collect_scan_policy<*,non_scan>
    
Can you see any flaws in that argument?

Hans: Could the prox_descriptor somewhat like that in the above
main.cpp be used in place of GC_descr [
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc_typedh.txt
]?

Boosters: If the stl standard could be changed to allow using a proxy
for the "container root pointer" (as for example, the
prox_vec::m_proxies in the above main.cpp) for all stl containers,
then I think maybe very little would have to change in user's code and
they could specify gc containers by simply passing another template
parameter or possible a different allocator type.  This might avoid
the reluctance to adopt the shared_array as described in:

http://aspn.activestate.com/ASPN/Mail/Message/1183330

What do booster's think?

DavidHeld: I've not recieved much feedback on my past posts, and I'm
guessing it's because of the lack of documentation that you mentioned
in:

http://aspn.activestate.com/ASPN/Mail/Message/1383272

How does a pattern description something like:

     Participants:
         descriptor_of_singleton
            - descriptor*
                 descriptor for subject_start
            - subject_start*
                  start of subject currently  being "described"
         descriptor_of<Subject>
            - sets above singleton pointers to descriptor for Subject
              and start of dummy Subject before constructing Subject.
         prox_record_scalar
            - IF subject_start, then records offsets from it.
         prox_record_container
            - IF subject_start, then record iterator maker for that 
container

Of course, there'd be more details, but that's basically it.  The other
details about the gc algorithm (whether Christopher's or Lins or
classic mark-sweep) would be left till later or just documented with
references to the literature.  This is because with prox_descriptor
and a bridge_iterator (taking a stack of concrete virtual iterators)
the method of getting the children of any node could simply be storing
a pointer to it as part of the allocated memory, making it a return
from a virtual function, or using the count_base* in shared_ptr to get
at the actual type and then retrieve the descriptor from
descriptor_of<Subject>.

Comments? Questions?  Please let me know what I should do to
get more feedback.