Hello All,
I would like to add destroyable objects into Ggc (the GCC garbage collector,
see files
gcc/ggc*.[ch]).
The main motivation is to permit C++ objects to be garbage collected (I
discussed that
briefly in the Gcc meeting at Google in London): adding destroyable object is a
prerequisite for that goal.
##### What are destroyable Ggc objects?
What do I call a destroyable object: it is a memory zone, allocated inside Ggc
heap,
which is provided a destructor routine at allocation time.
So the following should be added into ggc.h:
/* Signature of destructors, as known to GGC. */
typedef void (ggc_destructor_t) (void*);
/* Allocate an object with cleared memory and destructor */
extern void *ggc_internal_alloc_destroyed_stat (size_t, ggc_destructor_t*
MEM_STAT_DECL); #define ggc_internal_alloc_destroyed(Sz,Destr)
ggc_internal_alloc_destroyed_stat(Sz, Destr, MEM_STAT_INFO)
In my opinion, destroyable objects will be quite rare in the Ggc heap (because
most of
the data in the Ggc heap is stuff like tree, gimple, ... and they don't need
destructors,
being pure memory things). However, destroyable objects can be useful for C++
data (I
admit that we don't use C++ for Ggc data yet), and more significantly for data
allocated
thru some library, like PPL [Parma Polyhedra Library, notably used by Graphite]
data
(even using the C interface to PPL, since PPL is coded in C++, PPL data needs
to be
explicitly destroyed), or GMP data, etc.
Plugins will profit from destroyable objects. In particular, MELT would profit
from them.
Currently, there is a special hack inside the MELT runtime to deal with PPL
boxed data,
and it is a bit of a pain (and the hack is MELT specific).
##### external API and allocation of destroyable objects
GCC code wanting to allocate a destroyable object should first define a
destructor
function, like in C:
struct somedestroyable_st { .... };
static void my_destructor(struct somedestroyable_st*thing)
{ // code to destroy thing
}
Then allocate such objects with
struct somedestroyable_st* ob =
(struct somedestroyable_st*)
gcc_internal_alloc_destroyed(sizeof(struct somedestroyable_st),
my_destructor);
This means that Ggc -which is a precise, mark & sweep collector, so it knows
when every
object is destroyed- would call my_destructor before de-allocating ob. The
destructor
routine my_destructor should not itself allocate any Ggc-allocated data.
Zone for destroyed data should always be allocated with all bits cleared. This
simplifies
the code, and ensure that after initialization the zone contain some
deterministic
content. I don't feel that we should care about allocating destoyable objects in
uninitialized memory.
Of course, with C++, the destructor routine is really what C++ calls a
destructor, e.g
something like extern "C" void my_destructor_for_class_C (class C* p)
{ delete (p) p; // call the placement version of operator delete, from <new>
C++ library
header. }
##### implementation tricks
First, I am looking into gcc/ggc-zone.c and I feel that each page entry should
have some destructor related data (which may be cleared if no destructor is
involved).
For large_page_entry each large object has such a page [one page per large
object], and
the page can easily contain a function pointer to the destructor.
For small_page_entry which contains several chunks for several objects, I have
the
feeling that we would have an array of destructor function pointers (or null).
I am not sure to understand the exact role of alloc_bits in small_page_entry
structure. I
believe that a bit is set there only for start address of each object, not for
the entire
range of the object. Could someone confirm my understanding please?
With gcc/ggc-page.c I believe we should have an array of destructors inside the
page_entry structures.
############
Comments and helps are very welcome.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
