From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4884 invoked by alias); 18 Oct 2011 15:12:25 -0000 Received: (qmail 4872 invoked by uid 22791); 18 Oct 2011 15:12:24 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC,TO_NO_BRKTS_DYNIP,TVD_RCVD_IP X-Spam-Check-By: sourceware.org Received: from 195-14-0-142.nuxit.net (HELO de558.ispfr.net) (195.14.0.142) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 18 Oct 2011 15:12:10 +0000 Received: from ours.starynkevitch.net ([213.41.244.95] helo=glinka.lesours) by de558.ispfr.net with smtp (Exim 4.72) (envelope-from ) id 1RGBKq-0001sA-Lk for gcc@gcc.gnu.org; Tue, 18 Oct 2011 17:12:08 +0200 Date: Tue, 18 Oct 2011 16:35:00 -0000 From: Basile Starynkevitch To: gcc@gcc.gnu.org Subject: adding destroyable objects into Ggc Message-Id: <20111018171201.361304028ab94f102f827bd2@starynkevitch.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00277.txt.bz2 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 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: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***