adding destroyable objects into Ggc

[Basile Starynkevitch <basile@starynkevitch.net>]

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} ***