adding destroyable objects into Ggc

adding destroyable objects into Ggc

[Basile Starynkevitch]

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

Re: adding destroyable objects into Ggc

[Duncan Sands]

Hi Basile,

> 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.

it is already possible to have garbage collected C++ objects with destructors.
I use this in the dragonegg plugin (see the file Cache.cpp).  I do only use
htab's though, which comes with support for destructors.  After allocating the
garbage collected memory, I construct the object using placement new.  The
memory is allocated using htab_create_ggc, the last argument of which is a
destructor function which in my case does a call to the objects destructor.

Ciao, Duncan.

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Tue, 18 Oct 2011 17:19:56 +0200
Duncan Sands <baldrick@free.fr> wrote:

> Hi Basile,
> 
> > 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.
> 
> it is already possible to have garbage collected C++ objects with destructors.
> I use this in the dragonegg plugin (see the file Cache.cpp).  I do only use
> htab's though, which comes with support for destructors.  

Thanks for the tip.

I'm not sure to understand what you mean, and I did have a look into the htab_create_ggc
macro of gcc/ggc.h and also at lvm.org/viewvc/llvm-project/dragonegg/trunk/src/Cache.cpp

To be concrete:

How do you create inside Ggc heap an instance of std::ostringstream (as provided by the
standard C++ library) or of std::string ?

or, to be more Gcc specific,
how do you create inside Ggc heap a PPL constraint, that is a pointer to a 
struct ppl_Constraint_tag*, ie a ppl_Constraint_t opaque type, which should call
ppl_delete_Constraint at destruction time?

I don't want to have an explicit hash-table keeping these things... (because I have no
specific hash keys for them). Or are you suggesting it is the way to have destructed
objects in Ggc? Are these hash-tables weak, in the sense that when nothing points to the
value, the association of the key to the value is removed?

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

Re: adding destroyable objects into Ggc

[Ian Lance Taylor]

Basile Starynkevitch <basile@starynkevitch.net> writes:

> I would like to add destroyable objects into Ggc (the GCC garbage collector, see files
> gcc/ggc*.[ch]).

I think this type of thing is conventionally called a "finalizer".

I'm ambivalent leaning to negative to adding this feature to the gcc
garbage collector.  In the long run I would like to use the gcc garbage
collector less and less.  I believe that we can use C++ smart pointers
to move in that direction.  I understand that you want to take advantage
of the gcc garbage collector for the MELT plugin.  However, in my ideal
world you should be planning for the MELT plugin to take over garbage
collection entirely, rather than relying on gcc's garbage collector.

Ian

Re: adding destroyable objects into Ggc

[Gabriel Dos Reis]

On Tue, Oct 18, 2011 at 11:35 AM, Ian Lance Taylor <iant@google.com> wrote:

> I think this type of thing is conventionally called a "finalizer".
>
> I'm ambivalent leaning to negative to adding this feature to the gcc
> garbage collector.  In the long run I would like to use the gcc garbage
> collector less and less.

Fully agreed.

> [...] I understand that you want to take advantage
> of the gcc garbage collector for the MELT plugin.  However, in my ideal
> world you should be planning for the MELT plugin to take over garbage
> collection entirely, rather than relying on gcc's garbage collector.

again, agreed.

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Tue, 18 Oct 2011 09:35:16 -0700
Ian Lance Taylor <iant@google.com> wrote:

> Basile Starynkevitch <basile@starynkevitch.net> writes:
> 
> > I would like to add destroyable objects into Ggc (the GCC garbage collector, see files
> > gcc/ggc*.[ch]).
> 
> I think this type of thing is conventionally called a "finalizer".

Yes, if you like it. However both Boehm's GC and Java GC attach a more specific (and
perhaps more powerful) meaning to that term.

> I'm ambivalent leaning to negative to adding this feature to the gcc
> garbage collector.  In the long run I would like to use the gcc garbage
> collector less and less.  I believe that we can use C++ smart pointers
> to move in that direction.  


As far as I understand, we don't move much towards that direction. tree-s, gimple-s,
gimple_seq-s, edge-s, are still managed by Ggc (and on that particular aspect things
don't seem to change in the trunk, it is the same as in GCC-4.4, GCC-4.5, GCC-4.6: these
data types need Ggc.).

I believe I will be able to manage the MELT runtime to use whatever memory management the
community will agree upon (otherwise, it would mean that MELT is dead). In the worst
case, the MELT plugin would provide its self-sufficient GC (currently MELT GC is backed up
by Ggc: the MELT GC is copying generational, and its old generation is the Ggc heap).

But [independently of MELT] I don't believe that GCC will be able to return to manual
memory management. There have been valid reasons (long time ago) to implement Ggc, and as
far as I understand GCC, I don't see these reasons becoming invalid, on the contrary. I
don't like much the implementation of Ggc [in particular, I badly dislike the lack of
support for local variables in it], but I do believe that a five-million line compilers
(or 8MLOC, depending how you count them) with a community of hundreds of developers badly
need an automated way to deal with memory.

Did you notice any recent changes in Gcc which decrease the utility of Ggc?

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

Re: adding destroyable objects into Ggc

[Ian Lance Taylor]

On Tue, Oct 18, 2011 at 9:52 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
>
> But [independently of MELT] I don't believe that GCC will be able to return to manual
> memory management. There have been valid reasons (long time ago) to implement Ggc, and as
> far as I understand GCC, I don't see these reasons becoming invalid, on the contrary. I
> don't like much the implementation of Ggc [in particular, I badly dislike the lack of
> support for local variables in it], but I do believe that a five-million line compilers
> (or 8MLOC, depending how you count them) with a community of hundreds of developers badly
> need an automated way to deal with memory.
>
> Did you notice any recent changes in Gcc which decrease the utility of Ggc?

My hope is that as we move toward compiling gcc in C++, we will be able to use
smart pointer classes for memory with ambiguous lifetimes.

Ian

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Tue, 18 Oct 2011 09:35:16 -0700
Ian Lance Taylor <iant@google.com> wrote:

> [...] I understand that you want to take advantage
> of the gcc garbage collector for the MELT plugin.  However, in my ideal
> world you should be planning for the MELT plugin to take over garbage
> collection entirely, rather than relying on gcc's garbage collector.


Historically, it was the opposite: I do recognize the importance of garbage collection,
and because of the importance of Ggc in GCC, I designed MELT garbage collection above Ggc.

Still, I find strange that while some very smart & nice GCC guys want to get rid of Ggc,
no patch made into the trunk towards that goal (which I Basile dislike and don't share,
so don't expect me Basile to work on this.).

Isn't the fact that Ggc is still useful (despite it numerous shortcomings) & widely
used in Gcc a signal, or a symptom, of its utility?

If Ggc is useless, why is it still here? Why didn't we saw lots of patches to get rid of
it?

My strong belief is that any *big* compiler needs some automated way to deal with memory
(including circular references, which auto_ptr is not very happy about). It can be Ggc (I
am not very happy of it) or something else.

But again, if many people (not me Basile) believe that Ggc is useless, why is it not
disappearing from the GCC trunk?

And in my perception, auto_ptr are a poor man's way of implementing a garbage collection,
it is not a way to avoid it.

Obviously, if I want MELT to stay, I will adapt it to whatever memory management strategy
GCC is using (otherwise MELT becomes useless). Indeed, if GCC switches to a fully manual
memory management (where every pointer is obtained by new and released by delete, in C++
parlance) I might change the MELT runtime to have its own Gc following such a rule (which
I find inadequate for a large software like GCC). But I won't put any effort in removing
automatic memory management from GCC, because in my view it would be a tragic mistake:
most newcomers to GCC won't be able to write new code...

My point is totally independent of MELT: having some automatic way to deal with memory
management ease the work of GCC developers (in particular of newbies) and increase the
productivity of new GCC developers. On the contrary, requiring new developers to be able
to code without bugs all the delete statements (in C++ parlance) is a big impediment [in
particular because a compiler does have circular references, and some of the
circularities are global to the compiler, not local to a single pass].

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

Re: adding destroyable objects into Ggc

[Ian Lance Taylor]

On Tue, Oct 18, 2011 at 10:13 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
>
> Still, I find strange that while some very smart & nice GCC guys want to get rid of Ggc,
> no patch made into the trunk towards that goal (which I Basile dislike and don't share,
> so don't expect me Basile to work on this.).

I've put a lot of work into making it possible to build gcc as a C++ program.

It's true that these things move slowly.  GCC has been around for many years,
and fundamental changes to it take years to implement.

Ian

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Tue, 18 Oct 2011 10:36:08 -0700
Ian Lance Taylor <iant@google.com> wrote:

> On Tue, Oct 18, 2011 at 10:13 AM, Basile Starynkevitch
> <basile@starynkevitch.net> wrote:
> >
> > Still, I find strange that while some very smart & nice GCC guys want to get rid of Ggc,
> > no patch made into the trunk towards that goal (which I Basile dislike and don't share,
> > so don't expect me Basile to work on this.).
> 
> I've put a lot of work into making it possible to build gcc as a C++ program.

I do know that, and as many GCC developers I am grateful to you Ian for your big work.

However, I don't know very well auto_ptr.  Could you explain to use how do they deal with
*circular* memory references.... (perhaps by taking as examples code inside GCC).
My feeling is that auto_ptr is not able to deal with them, but I'll be delighted to be
proven wrong. 


Cheers.

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

Re: adding destroyable objects into Ggc

[Jonathan Wakely]

On 18 October 2011 18:41, Basile Starynkevitch wrote:
>
> However, I don't know very well auto_ptr.  Could you explain to use how do they deal with
> *circular* memory references.... (perhaps by taking as examples code inside GCC).
> My feeling is that auto_ptr is not able to deal with them, but I'll be delighted to be
> proven wrong.

Noone except you mentioned auto_ptr.

Something like shared_ptr is a better choice in some cases, and its
companion weak_ptr can be used to break cycles.

Re: adding destroyable objects into Ggc

[Ian Lance Taylor]

On Tue, Oct 18, 2011 at 10:41 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Tue, 18 Oct 2011 10:36:08 -0700
> Ian Lance Taylor <iant@google.com> wrote:
>
>> On Tue, Oct 18, 2011 at 10:13 AM, Basile Starynkevitch
>> <basile@starynkevitch.net> wrote:
>> >
>> > Still, I find strange that while some very smart & nice GCC guys want to get rid of Ggc,
>> > no patch made into the trunk towards that goal (which I Basile dislike and don't share,
>> > so don't expect me Basile to work on this.).
>>
>> I've put a lot of work into making it possible to build gcc as a C++ program.
>
> I do know that, and as many GCC developers I am grateful to you Ian for your big work.
>
> However, I don't know very well auto_ptr.  Could you explain to use how do they deal with
> *circular* memory references.... (perhaps by taking as examples code inside GCC).
> My feeling is that auto_ptr is not able to deal with them, but I'll be delighted to be
> proven wrong.

auto_ptr is confusing and hard to use.  Don't think about it.

I think a better approach here is likely to be a reference counted
shared_ptr for the
most general case.  It's true that it works poorly with cycles, but
gcc data structures
are only occasionally cyclical.

Also, I think that actually many cases in gcc do not require
shared_ptr.  Instead, we
can think of terms of pools, with the smart pointers being aware of
which pool they are
associated with.  Then we can detect at compile time an accidental use
of a pointer to
one pool being assigned to a pointer to a different pool.  Before we
introduced garbage
collection, gcc used pools (well, obstacks), but there were severe
problems because
pointers to one pool would be assigned to a pointer to a different
pool and then become
dangling pointers when the first pool was deleted.  C++ will let us
avoid that problem.

Ian

Re: adding destroyable objects into Ggc

[Jonathan Wakely]

On 18 October 2011 16:12, Basile Starynkevitch wrote:
>
> 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. }

Why not just call the destructor?

   p->~C()

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Tue, 18 Oct 2011 18:53:07 +0100
Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

> On 18 October 2011 16:12, Basile Starynkevitch wrote:
> >
> > 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. }
> 
> Why not just call the destructor?
> 
>    p->~C()

You are right. But I was also thinking of giving a C ABI to these destructors.

Cheers.


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

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Tue, 18 Oct 2011 10:50:11 -0700
Ian Lance Taylor <iant@google.com> wrote:
> 
> I think a better approach here is likely to be a reference counted
> shared_ptr for the
> most general case.  It's true that it works poorly with cycles, but
> gcc data structures
> are only occasionally cyclical.
> 
> Also, I think that actually many cases in gcc do not require
> shared_ptr.  Instead, we
> can think of terms of pools, with the smart pointers being aware of
> which pool they are
> associated with.  Then we can detect at compile time an accidental use
> of a pointer to
> one pool being assigned to a pointer to a different pool.  Before we
> introduced garbage
> collection, gcc used pools (well, obstacks), but there were severe
> problems because
> pointers to one pool would be assigned to a pointer to a different
> pool and then become
> dangling pointers when the first pool was deleted.  C++ will let us
> avoid that problem.


Where we probably disagree, is that you Ian believe apparently that such an ad-hoc
approach is scalable to a 10MLOC software with contributions by hundreds of people (most
of them understanding only a tiny part of GCC), while I Basile believe that such approach
won't work in practice, because of the enormous size of GCC [it is more and more a ten
million lines program] and the large size [hundred of developers] & heterogeneity [many
developers, me included, understand a tiny part of GCC] of its developpers' community.

My personal feeling is that human blood (the one flowing in developers' brains] is the
resource that is the scariest in GCC. It is more expensive than CPU time or RAM modules.
And I am a bit concerned about the too small number of young people attracted to work
inside GCC. So stuff that would help them, even if GCC takes a few more milliseconds to
compile files, is from my point of view important. And I think an automated GC would help
them. (Or perhaps should we wait to switch to C++ till C++2011 is common enough, and
provide good enough GCs).

Cheers.


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

Re: adding destroyable objects into Ggc

[Jonathan Wakely]

On 18 October 2011 19:03, Basile Starynkevitch wrote:
> On Tue, 18 Oct 2011 18:53:07 +0100
> Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
>> On 18 October 2011 16:12, Basile Starynkevitch wrote:
>> >
>> > 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. }
>>
>> Why not just call the destructor?
>>
>>    p->~C()
>
> You are right. But I was also thinking of giving a C ABI to these destructors.

Yes, I understand that, I wasn't talking about the C interface.

I assume you haven't tried to compile your suggested code, because
1) your destructor function doesn't match the ggc_destructor_t signature.
2) you can't call placement delete like that
3) the placement delete in <new> is a no-op

You probably want something like this:

extern "C" void my_destructor_for_class_C (void* p)
{ static_cast<C*>(p)->~C(); }

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Tue, 18 Oct 2011 19:39:03 +0100
Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> 3) the placement delete in <new> is a no-op

I thought every delete in C++ calls the destructor, and that the placement delete does
only that. I mean that a delete statement does two things: invoke the destructor first,
and then does whatever the operator delete does (which for the placement delete operator
is indeed a no-op).

So I thought that 
  delete (p) p;
actually called p->~C()


Cheers.


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

Re: adding destroyable objects into Ggc

[Gabriel Dos Reis]

On Tue, Oct 18, 2011 at 12:13 PM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:

> And in my perception, auto_ptr are a poor man's way of implementing a garbage collection,
> it is not a way to avoid it.

I saw several mentions of smart pointers, and no mention -- except in
this message I am replying to -- of auto_ptr.

I also think you should not read too much into "manual storage management".

Re: adding destroyable objects into Ggc

[Gabriel Dos Reis]

On Tue, Oct 18, 2011 at 12:41 PM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:

> However, I don't know very well auto_ptr.

why do you believe you have to focus on auto_ptr?

Re: adding destroyable objects into Ggc

[Gabriel Dos Reis]

On Tue, Oct 18, 2011 at 12:50 PM, Ian Lance Taylor <iant@google.com> wrote:
> Before we introduced garbage collection, gcc used pools (well, obstacks),

When I started in 1997, obstack was still there and it isn't that long ago, so
things do move fast -- for a large software like GCC.

> but there were severe
> problems because
> pointers to one pool would be assigned to a pointer to a different
> pool and then become
> dangling pointers when the first pool was deleted.  C++ will let us
> avoid that problem.

Exactly.

Re: adding destroyable objects into Ggc

[Gabriel Dos Reis]

On Tue, Oct 18, 2011 at 1:03 PM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Tue, 18 Oct 2011 18:53:07 +0100
> Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
>> On 18 October 2011 16:12, Basile Starynkevitch wrote:
>> >
>> > 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. }
>>
>> Why not just call the destructor?
>>
>>    p->~C()
>
> You are right. But I was also thinking of giving a C ABI to these destructors.

why?

In a good design, you almost never want to do that.

Re: adding destroyable objects into Ggc

[Gabriel Dos Reis]

On Tue, Oct 18, 2011 at 1:48 PM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:

> So I thought that
>  delete (p) p;
> actually called p->~C()
>

No.  This is one of the reasons why you should not read too much
into "manual storage management".  Most of the time, you don't have
to say delete.  And if you do, think twice.  I suspect that is the design
envisioned for GCC.

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Tue, 18 Oct 2011 14:42:34 -0500
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> On Tue, Oct 18, 2011 at 12:41 PM, Basile Starynkevitch
> <basile@starynkevitch.net> wrote:
> 
> > However, I don't know very well auto_ptr.
> 
> why do you believe you have to focus on auto_ptr?

I actually meant <any-kind-of>_ptr template C++ class.

I don't know them much. Any pointers to a tutorial to these smart or whatever you call
them _ptr-s?

Cheers.

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

Re: adding destroyable objects into Ggc

[Jonathan Wakely]

On 18 October 2011 21:52, Basile Starynkevitch wrote:
>
> I actually meant <any-kind-of>_ptr template C++ class.
>
> I don't know them much. Any pointers to a tutorial to these smart or whatever you call
> them _ptr-s?

You could try http://www.boost.org/libs/smart_ptr/

Re: adding destroyable objects into Ggc

[Chiheng Xu]

[-- Attachment #1: Type: text/plain, Size: 2313 bytes --]

On Wed, Oct 19, 2011 at 1:13 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
>
> Historically, it was the opposite: I do recognize the importance of garbage collection,
> and because of the importance of Ggc in GCC, I designed MELT garbage collection above Ggc.
>
>
> My strong belief is that any *big* compiler needs some automated way to deal with memory
> (including circular references, which auto_ptr is not very happy about). It can be Ggc (I
> am not very happy of it) or something else.
>
> But again, if many people (not me Basile) believe that Ggc is useless, why is it not
> disappearing from the GCC trunk?
>
> And in my perception, auto_ptr are a poor man's way of implementing a garbage collection,
> it is not a way to avoid it.
>

It seems that this thread needs some balance.

Basile, I completely agree with you.

I recommend people interested in automatic dynamic memory management
to read this book:
Garbage Collection: Algorithms For Automatic Dynamic Memory
Management(Richard Jones,1996)

The importance of garbage collection in large software project and why
reference counting based solution is inefficient  and can't be  good
general "garbage collection" mechanism is clearly explained.


As a non-compiler developer, I want to share my experience in studying
 GCC's source code.
When I first read GCC's source code several years ago, I was totally
confused by the GGC markers here and there.
Basically, I just don't understand their precise meaning. And I'm
afraid I don't know how to add them.
My source code analyzer(a proprietary software on Windows) was also
confused/poisoned by the GGC markers.

The result is that I crafted a script that can remove nearly
all(99.9%) GGC markers in GCC source tree, then my source code
analyzer and I were both happy. I also attach the scripts.

When not seeing the GGC markers,  my brain is much relaxed.  I can be
more focused on the logic of compiler, don't worry about memory
management issues. In this way, I found GCC's source code was not that
horrible.  It turned out to be simple and easy to understand
"suddenly".

My point is that, when a programmer don't need to worry about memory
management issue,  his/her productivity is maximized.


--
Chiheng Xu

[-- Attachment #2: gcc_clean_scripts.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 2143 bytes --]

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Wed, 19 Oct 2011 13:22:41 +0800
Chiheng Xu <chiheng.xu@gmail.com> wrote:
> 
> Basile, I completely agree with you.
> 
> I recommend people interested in automatic dynamic memory management
> to read this book:
> Garbage Collection: Algorithms For Automatic Dynamic Memory
> Management(Richard Jones,1996)
> 
> The importance of garbage collection in large software project and why
> reference counting based solution is inefficient  and can't be  good
> general "garbage collection" mechanism is clearly explained.
> 
> 
> As a non-compiler developer, I want to share my experience in studying
>  GCC's source code.


If you want to extend, alter or improve GCC source code in a garbage collected language,
please consider trying MELT (see http://gcc-melt.org/ for more). MELT is a domain
specific language (garbage collected, lispy syntax, with high order functions & objects &
pattern matching) designed for GCC extensions.

[sorry for the shameless plug, I am the main author of MELT]

And MELT garbage collector fits very well in Gcc, it is a copying GC built above Ggc.

Cheers.

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

Re: adding destroyable objects into Ggc

[Gabriel Dos Reis]

On Wed, Oct 19, 2011 at 12:22 AM, Chiheng Xu <chiheng.xu@gmail.com> wrote:

> I recommend people interested in automatic dynamic memory management
> to read this book:
> Garbage Collection: Algorithms For Automatic Dynamic Memory
> Management(Richard Jones,1996)

There is no reason to assume or to believe that people who argue for
less GC aren't familiar with GC --  a regrettably  not so uncommon
jugemental mistake.

In fact, the book you mention has been part of my essential books since
the year of its publication, and my  other daytime job essentially relies GC.

-- Gaby

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Wed, 19 Oct 2011 00:45:58 -0500
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> 
> There is no reason to assume or to believe that people who argue for
> less GC aren't familiar with GC --  a regrettably  not so uncommon
> jugemental mistake.

However, I don't often see the people arguing against Ggc talking about the difficulties
for GCC newscomers to dive inside GCC and be able to propose code. In particular, I did
not understand any coding rules or guidelines, or even hypothetical examples, which, when
GCC becomes manually memory managed (and the smart or whatever _ptr-s offered by C++
fall into this), will help them to avoid memory leaks.

(and while I agree Ggc is somehow weak, I'm in the minority who believes a garbage
collector is needed, and Ggc should be improved or replaced by a better garbage collector,
not removed; my GC belief is mostly motivated to help new GCC developers, and because of
GCC enormous size).

Even more, I saw no patches submitted to trunk to remove Ggc, and I saw no patches
submitted to trunk to "improve" core Gcc internal representations (tree-s, gimple-s,
gimple_seq-s, edge-s ...) by using C++ language constructs. It even has never been
discussed in details. I sincerely have absolutely no idea how smart or whatever kind of
_ptr-s in C++ will permit moving gimple-s or tree-s outside of Ggc (to the point that I
believe it is not realistically achievable). I'll be delighted to get explanations &
"proof-of-concept" style code samples.

Cheers.

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

Re: adding destroyable objects into Ggc

[Chiheng Xu]

On Wed, Oct 19, 2011 at 1:45 PM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> There is no reason to assume or to believe that people who argue for
> less GC aren't familiar with GC --  a regrettably  not so uncommon
> jugemental mistake.
>
> In fact, the book you mention has been part of my essential books since
> the year of its publication, and my  other daytime job essentially relies GC.
>
I'm really sorry for the misunderstanding.

The only reason I refer to that book, is that, my English is not
fluent enough to clearly explain my opinion.  That book said all I
want to say.

No other meaning.

-- 
Chiheng Xu

Re: adding destroyable objects into Ggc

[Chiheng Xu]

On Wed, Oct 19, 2011 at 1:44 PM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
>
> If you want to extend, alter or improve GCC source code in a garbage collected language,
> please consider trying MELT (see http://gcc-melt.org/ for more). MELT is a domain
> specific language (garbage collected, lispy syntax, with high order functions & objects &
> pattern matching) designed for GCC extensions.
>
> [sorry for the shameless plug, I am the main author of MELT]
>
> And MELT garbage collector fits very well in Gcc, it is a copying GC built above Ggc.
>

I'll try it if I have enough time . Thank you!

-- 
Chiheng Xu

adding destroyable objects into Ggc

[Gabriel Dos Reis]

On Wed, Oct 19, 2011 at 1:00 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:

> However, I don't often see the people arguing against Ggc talking about the difficulties
> for GCC newscomers to dive inside GCC and be able to propose code.

From my experience, the difficulty for newcomer to get into GCC source
code base has less to do with GC than the compiler overall architecture
itself.  I believe it would be naively deceptive to make people believe that
the absence of GC is what makes or would make GCC impenetrable to newcomers.

-- Gaby

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Wed, 19 Oct 2011 01:16:03 -0500
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> On Wed, Oct 19, 2011 at 1:00 AM, Basile Starynkevitch
> <basile@starynkevitch.net> wrote:
> 
> > However, I don't often see the people arguing against Ggc talking about the difficulties
> > for GCC newscomers to dive inside GCC and be able to propose code.
> 
> From my experience, the difficulty for newcomer to get into GCC source
> code base has less to do with GC than the compiler overall architecture
> itself.  I believe it would be naively deceptive to make people believe that
> the absence of GC is what makes or would make GCC impenetrable to newcomers.


I half agree about it. Look at Qt & GTK documentation: both starts about how
memory management of their objects should be done. And I have no idea about what the
equivalent would be for hypothetical tree-s, gimple-s, edge-s, gimple_seq-s,
basic_block-s coded in C++ with some kind of _ptr.

I do think that the fact that some other big free software starts by explaining how to
manage their memory is significant.

I also agree with you that GCC architecture is messy, and that scares newscomer a lot.

Cheers. 

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

Re: adding destroyable objects into Ggc

[Gabriel Dos Reis]

On Wed, Oct 19, 2011 at 1:22 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:

> I do think that the fact that some other big free software starts by explaining how to
> manage their memory is significant.

Storage management is important.  However, I believe it is a mistake to
focus only on that or to start the presentation of a project with that.
No matter how popular it is.

> I also agree with you that GCC architecture is messy, and that scares newscomer a lot.
>

Yes, but the way we improve it isn't, in my opinion, adding more GC.
First we would like to remove complexity, and I do not think we should
start by focusing on storage management until we get a clearer idea
about lifetime of data structures we manipulate and how they mesh.
We might find out (as I suspect) that the builtin GC of C (or C++) is
remarkable at the job, provided we have a design that makes the
lifetime obvious and take advantage of it.

Re: adding destroyable objects into Ggc

[Duncan Sands]

Hi Gabriel,

>> I also agree with you that GCC architecture is messy, and that scares newscomer a lot.
>>
>
> Yes, but the way we improve it isn't, in my opinion, adding more GC.
> First we would like to remove complexity, and I do not think we should
> start by focusing on storage management until we get a clearer idea
> about lifetime of data structures we manipulate and how they mesh.
> We might find out (as I suspect) that the builtin GC of C (or C++) is
> remarkable at the job, provided we have a design that makes the
> lifetime obvious and take advantage of it.

what you say sounds very sensible to me.  If you look at LLVM, most memory
management is done by using container objects (vectors, maps etc) that
automatically free memory when they go out of scope.  This takes care
of 99% of memory management in a clean and simple way, which is a great
situation to be in.

Ciao, Duncan.

Re: adding destroyable objects into Ggc

[David Malcolm]

On Wed, 2011-10-19 at 00:45 -0500, Gabriel Dos Reis wrote:
> On Wed, Oct 19, 2011 at 12:22 AM, Chiheng Xu <chiheng.xu@gmail.com> wrote:
> 
> > I recommend people interested in automatic dynamic memory management
> > to read this book:
> > Garbage Collection: Algorithms For Automatic Dynamic Memory
> > Management(Richard Jones,1996)
> 
> There is no reason to assume or to believe that people who argue for
> less GC aren't familiar with GC --  a regrettably  not so uncommon
> jugemental mistake.
> 
> In fact, the book you mention has been part of my essential books since
> the year of its publication, and my  other daytime job essentially relies GC.
Possibly heading offtopic, but as of 2 months ago there's a sequel/new
edition (which I'm thoroughly enjoying):

The Garbage Collection Handbook: The Art of Automatic Memory Management
(Richard Jones, Antony Hosking, Eliot Moss, 2011)

ISBN: 978-1420082791

Hope this is helpful
Dave

Re: adding destroyable objects into Ggc

[Laurynas Biveinis]

Basile -

2011/10/18 Basile Starynkevitch <basile@starynkevitch.net>:
> Still, I find strange that while some very smart & nice GCC guys want to get rid of Ggc,
> no patch made into the trunk towards that goal (which I Basile dislike and don't share,
> so don't expect me Basile to work on this.).

Well, there is my RTL-out-of-GC project to finish Bernd's work which
got stalled due to work and studies, and certainly won't be finished
for 4.7.

In the end I believe that it is the patches that talk. Whatever
patches are going to be submitted, reviewed and accepted, that is
going to be GCC's future, be it memory management, or something else.

-- 
Laurynas

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Wed, Oct 19, 2011 at 04:31:48PM +0300, Laurynas Biveinis wrote:
> In the end I believe that it is the patches that talk. Whatever
> patches are going to be submitted, reviewed and accepted, that is
> going to be GCC's future, be it memory management, or something els


I was beginning to work on a patch to add finalizable (that is destroyable)
objects to Ggc. So I understand you Laurynas suggest that it might be worth
working on it (while I percieved most other emails, e.g. Ian's or Duncan's
messages, as a hint to avoid losing my time). 

In http://gcc.gnu.org/ml/gcc/2011-10/msg00274.html I wrote:
##### 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.

############

Laurynas & others, do you understand precisely the role of alloc_bits? Is a
bit set for every machine word (or some elementary allocation unit) which is used,
or is it set only for the first word?

Do you think I should add some finalization related data to
small_page_entry, or do you suggest I need yet another kind of page_entry,
e.g. a finalizable_page_entry (for rather "small" finalized Ggc objects).?

Cheers.

-- 
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 mines, sont seulement les miennes} ***

Re: adding destroyable objects into Ggc

[Jonathan Wakely]

On 19 October 2011 08:42, Duncan Sands wrote:
> Hi Gabriel,
>
>>> I also agree with you that GCC architecture is messy, and that scares
>>> newscomer a lot.
>>>
>>
>> Yes, but the way we improve it isn't, in my opinion, adding more GC.
>> First we would like to remove complexity, and I do not think we should
>> start by focusing on storage management until we get a clearer idea
>> about lifetime of data structures we manipulate and how they mesh.
>> We might find out (as I suspect) that the builtin GC of C (or C++) is
>> remarkable at the job, provided we have a design that makes the
>> lifetime obvious and take advantage of it.
>
> what you say sounds very sensible to me.  If you look at LLVM, most memory
> management is done by using container objects (vectors, maps etc) that
> automatically free memory when they go out of scope.  This takes care
> of 99% of memory management in a clean and simple way, which is a great
> situation to be in.

And LLVM seems to be very popular with newcomers to the code base. My
impression is that noone working with the code is intimidated by
properly-managed object lifetimes and the lack of garbage collection.

Re: adding destroyable objects into Ggc

[Lawrence Crowl]

Basile Starynkevitch <basile@starynkevitch.net>
> 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.

The C++ standard has support for garbage collection, and the general
consensus of the committee is that object garbage collected do not
execute their destructors.

Can you be specific about the use case that is driving you towards
this solution?

Ian Lance Taylor <iant@google.com>
> I think this type of thing is conventionally called a "finalizer".

Basile Starynkevitch <basile@starynkevitch.net> writes:
> Yes, if you like it. However both Boehm's GC and Java GC attach a
> more specific (and perhaps more powerful) meaning to that term.

How is what you propose distinct from the finalization mechanism?
http://www.hpl.hp.com/personal/Hans_Boehm/gc/finalization.html

> But [independently of MELT] I don't believe that GCC will be able to
> return to manual memory management. There have been valid reasons
> (long time ago) to implement Ggc, and as far as I understand GCC, I
> don't see these reasons becoming invalid, on the contrary. I don't
> like much the implementation of Ggc [in particular, I badly dislike
> the lack of support for local variables in it], but I do believe
> that a five-million line compilers (or 8MLOC, depending how you
> count them) with a community of hundreds of developers badly need an
> automated way to deal with memory.

There is a world of difference between using manual memory management
in C and using smart pointers in C++.  The later can be handled, for
the most part, with local coding rules.  The former, not so much.
More importantly, the C++ standard library provides flexible data
structures so that programmers need not worry about either.

Basile Starynkevitch <basile@starynkevitch.net>
> My strong belief is that any *big* compiler needs some automated way
> to deal with memory (including circular references, which auto_ptr
> is not very happy about). It can be Ggc (I am not very happy of it)
> or something else.

While not entirely relevant, compiler needs a way to manage circular
relationships, but it does not need to manage circular pointers.
Programmers have gotten so accustomed to representing relationships
with pointers that the alternatives have almost been forgotten.

> And in my perception, auto_ptr are a poor man's way of implementing
> a garbage collection, it is not a way to avoid it.

Auto_ptr has known weaknesses, and has been supplanted by shared_ptr,
unique_ptr, and weak_ptr.  Even so, none of these are a "poor man's
garbage collector" as competent use of them leaves little garbage to
be collected.

Chiheng Xu <chiheng.xu@gmail.com>
> I recommend people interested in automatic dynamic memory management
> to read this book:  Garbage Collection: Algorithms For Automatic
> Dynamic Memory Management(Richard Jones,1996)
>
> The importance of garbage collection in large software project and
> why reference counting based solution is inefficient and can't be
> good general "garbage collection" mechanism is clearly explained.

I am willing to wager that the implicit assumption here is that
relationships are managed with pointers.

I am also willing to wager that the author is willing to accept a 5x
increase in memory use to get cited benefits.  While that tradeoff is
good for many applications, it is not good for all applications.

-- 
Lawrence Crowl

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Wed, 19 Oct 2011 21:17:47 -0700
Lawrence Crowl <crowl@google.com> wrote:

> Basile Starynkevitch <basile@starynkevitch.net>
> > 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.
> 
> The C++ standard has support for garbage collection, and the general
> consensus of the committee is that object garbage collected do not
> execute their destructors.

I don't understand well this decision. Do you have URLs describing it motivations?

> 
> Can you be specific about the use case that is driving you towards
> this solution?
> 


PPL [Parma Polyhedra Library] data, like e.g. ppl_Constraint_t [from header
<ppl_c.h> that is, using a C API] comes to mind. If you want to share PPL stuff between
several passes, it can be very handy to add PPL data inside GTY-ed stuff. If that GTY-ed
stuff is deleted by Ggc, and if the PPL destructor (e.g. ppl_delete_Constraint in that
case) is not called, you get a memory leak. (In the MELT runtime, I have a special cases
for things like that, and they are really ad-hoc). And sharing PPL data between several
passes is useful: a first pass detect some optimization situations using PPL, and a later
pass actually does the optimizations by modifying the Gimple-s...

Very probably, if Graphite passes will add hooks for plugins [current plugins have no
good way to find what Graphite consider as induction variables inside graphite-optimized
loops, except by looking into symbol names like "graphite_IV" inside SSA names; that
would be much easier if Graphite provides a hook to tell about them, so I do hope
Graphit will add more plugin hooks!], they will benefit from it; when discussing about
Graphite people at INRIA, I got the impression that they would be happy of such features
(and conversely, plugins, in particular MELT, would benefit from more hooks from
Graphite).

Other usages include other finalized data, like FILE* [if a plugin need a FILE* inside
GTY-ed data to be shared by several passes, it would be handy that when the GTY-ed object
is deleted, the FILE* is fclosed] or even std::ostringstream or std::ostring-s shared
between several passes.

Maybe a compilation server might also find finalization useful.

More generally, any resource which is added, e.g. by a plugin, into a GTY-ed type and
which is used by several passes could benefit of finalizers, because from inside a plugin
you cannot easily determine when a GTY-ed data is no more used.

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

Re: adding destroyable objects into Ggc

[Marc Glisse]

On Thu, 20 Oct 2011, Basile Starynkevitch wrote:

> On Wed, 19 Oct 2011 21:17:47 -0700
> Lawrence Crowl <crowl@google.com> wrote:
>
>> Basile Starynkevitch <basile@starynkevitch.net>
>>> 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.
>>
>> The C++ standard has support for garbage collection, and the general
>> consensus of the committee is that object garbage collected do not
>> execute their destructors.
>
> I don't understand well this decision.

If you just let the objects leak, their destructor is not executed. 
Garbage collection reuses that memory in such a way that you can't notice 
the difference with a leak (except that you don't get OOM).

> PPL [Parma Polyhedra Library] data, like e.g. ppl_Constraint_t [from 
> header <ppl_c.h> that is, using a C API] comes to mind. If you want to 
> share PPL stuff between several passes, it can be very handy to add PPL 
> data inside GTY-ed stuff. If that GTY-ed stuff is deleted by Ggc, and if 
> the PPL destructor (e.g. ppl_delete_Constraint in that case) is not 
> called, you get a memory leak.

Or you could imagine the garbage collector also reclaiming that memory.

> Other usages include other finalized data, like FILE* [if a plugin need 
> a FILE* inside GTY-ed data to be shared by several passes, it would be 
> handy that when the GTY-ed object is deleted, the FILE* is fclosed] or 
> even std::ostringstream or std::ostring-s shared between several passes.

Yes, those are the usual arguments for a finalizer.

-- 
Marc Glisse

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Thu, Oct 20, 2011 at 09:11:02AM +0200, Marc Glisse wrote:
> On Thu, 20 Oct 2011, Basile Starynkevitch wrote:
> >>Basile Starynkevitch <basile@starynkevitch.net>
> >>>I would like to add destroyable objects into Ggc (the GCC garbage
> >>>collector, see files gcc/ggc*.[ch]).
>
> >PPL [Parma Polyhedra Library] data, like e.g. ppl_Constraint_t
> >[from header <ppl_c.h> that is, using a C API] comes to mind. If
> >you want to share PPL stuff between several passes, it can be very
> >handy to add PPL data inside GTY-ed stuff. If that GTY-ed stuff is
> >deleted by Ggc, and if the PPL destructor (e.g.
> >ppl_delete_Constraint in that case) is not called, you get a
> >memory leak.
> 
> Or you could imagine the garbage collector also reclaiming that memory.


Yes, but that precisely is the finalization machinery we are talking about.

I'm beginning to work on that; I'll experiment inside the MELT branch, but
not using any MELT specific feature or code [I'm using the MELT branch
because it would be overkill to create a special branch for that]. The
question also becomes: is it worth working on it? and who will review the
patches I might submit?

Cheers.

-- 
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 mines, sont seulement les miennes} ***

Re: adding destroyable objects into Ggc

[Laurynas Biveinis]

Basile -

2011/10/19 Basile Starynkevitch <basile@starynkevitch.net>:
> On Wed, Oct 19, 2011 at 04:31:48PM +0300, Laurynas Biveinis wrote:
>> In the end I believe that it is the patches that talk. Whatever
>> patches are going to be submitted, reviewed and accepted, that is
>> going to be GCC's future, be it memory management, or something els
>
>
> I was beginning to work on a patch to add finalizable (that is destroyable)
> objects to Ggc. So I understand you Laurynas suggest that it might be worth
> working on it (while I percieved most other emails, e.g. Ian's or Duncan's
> messages, as a hint to avoid losing my time).

I'm not sure in this case. I think that C++ would reduce the need for
it, but you need the feature *now*, and GCC codebase is not C++ yet. I
agree with other suggestions that the safest option for you is to make
it MELT-specific. Or, you could use C++ in MELT.

In any case I cannot offer much of opinion, should you work on this or
not. Sorry.

-- 
Laurynas

Re: adding destroyable objects into Ggc

[Marc Glisse]

On Thu, 20 Oct 2011, Basile Starynkevitch wrote:

> On Thu, Oct 20, 2011 at 09:11:02AM +0200, Marc Glisse wrote:
>> On Thu, 20 Oct 2011, Basile Starynkevitch wrote:
>>> PPL [Parma Polyhedra Library] data, like e.g. ppl_Constraint_t
>>> [from header <ppl_c.h> that is, using a C API] comes to mind. If
>>> you want to share PPL stuff between several passes, it can be very
>>> handy to add PPL data inside GTY-ed stuff. If that GTY-ed stuff is
>>> deleted by Ggc, and if the PPL destructor (e.g.
>>> ppl_delete_Constraint in that case) is not called, you get a
>>> memory leak.
>>
>> Or you could imagine the garbage collector also reclaiming that memory.
>
> Yes, but that precisely is the finalization machinery we are talking about.

Er, if there is a leak, it means that memory is not referenced anymore, so 
it is up to the garbage collector to pick it up. If only some objects are 
marked for garbage collection, that may require some extra steps, but in 
principle, in the general context of garbage collection, I don't see why 
that would require a finalizer. Would you care to explain?

-- 
Marc Glisse

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Thu, Oct 20, 2011 at 10:38:04AM +0200, Marc Glisse wrote:
> On Thu, 20 Oct 2011, Basile Starynkevitch wrote
[...]
> >Yes, but that precisely is the finalization machinery we are talking about.
> 
> Er, if there is a leak, it means that memory is not referenced
> anymore, so it is up to the garbage collector to pick it up. If only
> some objects are marked for garbage collection, that may require
> some extra steps, but in principle, in the general context of
> garbage collection, I don't see why that would require a finalizer.


Suppose someone is coding a new plugin, which adds several passes to GCC (so
need the data to be managed by Ggc, because it is not internal to one single
pass.). Suppose the plugin is coded in C++, and that it uses some standard
C++ collection (e.g. std::vector or std::map) of C++ objects mixing pointers
to GTY-ed data (e.g. gimple) and PPL instances (in C++). The data used by
the plugin would better be GTY-ed. And it points to both GTY-ed & PPL data,
so need to be finalized.


Notice that plugins providing several cooperating passes nearly need the
data shared between their passes to be Ggc managed & GTY-ed.

A finalization mechanism inside Ggc is the first step. The second step is
support of some C++ classes by gengtype.

Cheers.

-- 
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 mines, sont seulement les miennes} ***

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Thu, Oct 20, 2011 at 11:28:40AM +0300, Laurynas Biveinis wrote:

> 2011/10/19 Basile Starynkevitch <basile@starynkevitch.net>:
> > On Wed, Oct 19, 2011 at 04:31:48PM +0300, Laurynas Biveinis wrote:
> >> In the end I believe that it is the patches that talk. Whatever
> >> patches are going to be submitted, reviewed and accepted, that is
> >> going to be GCC's future, be it memory management, or something els
> >
> >
> > I was beginning to work on a patch to add finalizable (that is destroyable)
> > objects to Ggc. So I understand you Laurynas suggest that it might be worth
> > working on it (while I percieved most other emails, e.g. Ian's or Duncan's
> > messages, as a hint to avoid losing my time).
> 
> I'm not sure in this case. I think that C++ would reduce the need for
> it, but you need the feature *now*, and GCC codebase is not C++ yet. I
> agree with other suggestions that the safest option for you is to make
> it MELT-specific. Or, you could use C++ in MELT.
> 
> In any case I cannot offer much of opinion, should you work on this or
> not. Sorry.


To be clear, I don't need finalized objects myself, and I don't need them
in MELT neither. (MELT runtime has already ad-hoc finalization for some few
MELT values, notably those boxing PPL stuff. That finalization uses the
existing Ggc plugin hooks.).

So, I am trying to add finalized objects in Ggc not for MELT (it does not
need them, and it already has some finalization tricks which I could use
when some GCC begins to use C++ objects), but for general use.

I still don't grasp how a future GCC coded in C++ could realistically avoid
Ggc, because nobody (amongst those advocating C++ smart or whatever _ptr-s)
explained how he believes the current GCC GTY-ed representations (like tree,
gimple, gimple_seq, edge, loop-s...) could be re-implemented in C++ using
C++ tricks without Ggc, and what could be the transition from the current
state of GCC to such a future state (C++--full, but Ggc-less) of GCC.

I'm quite confident that if I continue working on MELT (which I hope to, and
I believe I will) and if GCC is going entirely the C++ way (which I don't
hope that much, but apparently it is the way it is going) I would be able to
adapt MELT to whatever coding rules & styles GCC will require.

But I don't understand how Ggc could be avoided (and I am not sure to
understand how even LLVM can avoid any kind of garbage collection in the
long run).

What I do hope, is that when Gcc becomes written in C++, the coding rules
and styles for manual memory management would be well documented.

Apparently, adding finalization into Ggc seems quite easy (but until I did
it, I can be wrong). And my feeling is that, together with some support for
GTY-ed classes in gengtype, that could offer a realistic transition route to
more C++ inside GCC.

And be able to use more of PPL stuff inside plugins and passes seems to
motivate & justify adding finalizers in Ggc (and later, C++ support in
gengtype).

I might be grossly wrong, but nobody explained -with concrete examples- us
how the current major GCC representations could be done inside GCC with C++
but without Ggc. For instance, nobody explained what an hypothetical class
Gimple or class Gimple_Seq could be.

Cheers.
-- 
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 mines, sont seulement les miennes} ***

Re: adding destroyable objects into Ggc

[Andrew Haley]

On 10/20/2011 12:56 PM, Basile Starynkevitch wrote:
> So, I am trying to add finalized objects in Ggc not for MELT (it does not
> need them, and it already has some finalization tricks which I could use
> when some GCC begins to use C++ objects), but for general use

For what general use?  Surely you're not proposing to add a feature
for which you have no use.

Andrew.

Re: adding destroyable objects into Ggc

[Duncan Sands]

Hi Basile,

> But I don't understand how Ggc could be avoided (and I am not sure to
> understand how even LLVM can avoid any kind of garbage collection in the
> long run).

I doubt LLVM will ever need garbage collection, because the way it is designed
makes memory management easy.  I already mentioned the use of containers, but
of course containers can't handle everything.  So consider a typical thing you
might want to do: replace an instruction I1 by a different one I2 (for example
because you understood that I1 simplifies to the simpler instruction I2) and
delete I1.  You can think of an LLVM instruction as being a gimple
statement.  One of the design points of LLVM is that instructions always know
about all users of the instruction (def-use chains are built in).  Thus you
can do
   I1->replaceAllUsesWith(I2);
and at this point everything using I1 as an operand now uses I2 instead.  Thus
the only place still referring to I1 is the function that the instruction I1
is linked into.  You can unlink it and free the memory for I1 as follows
   I1->eraseFromParent();
And that's it.  The price you pay for this simplicity is the need to keep track
of uses - and this does cost compilation time (clear to anyone who does some
profiling of LLVM) but it isn't that big.  The big advantage is that memory
management is easy - so easy that I suspect many LLVM users never thought
about the design choices (and trade-offs) that make it possible.

Ciao, Duncan.

PS: You may wonder about copies of I1 cached in a map or whatnot, where it can
be tricky (eg breaks an abstraction) or expensive to flush I1 from the data
structure.  This situation is handled conveniently by an extension of the above
mechanism where in essence your copy of I1 in the data structure can register
itself as an additional user of I1.  When I1 is replaced by I2 then (according
to how you chose to set things up) either the copy in the data structure gets
turned into I2, or nulled out, or a special action of your choice is performed.

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Thu, Oct 20, 2011 at 01:09:56PM +0100, Andrew Haley wrote:
> On 10/20/2011 12:56 PM, Basile Starynkevitch wrote:
> > So, I am trying to add finalized objects in Ggc not for MELT (it does not
> > need them, and it already has some finalization tricks which I could use
> > when some GCC begins to use C++ objects), but for general use
> 
> For what general use?  Surely you're not proposing to add a feature
> for which you have no use.


Because I don't understand how we can make a realistic & smooth transition
from current GCC trunk to a future GCC in C++ without such a feature.

Or is the grandiose plan to rewrite entirely GCC in C++ without making that
gradual?

And also because I still stand convinced that a good garbage collector is
useful inside GCC. (the "Resource Acquisition Is Initialization" mantra
would probably mean a big lot of copied data and a lot of used memory).

Cheers.


-- 
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 mines, sont seulement les miennes} ***

Re: adding destroyable objects into Ggc

[Torvald Riegel]

On Thu, 2011-10-20 at 14:27 +0200, Duncan Sands wrote:
> And that's it.  The price you pay for this simplicity is the need to keep track
> of uses - and this does cost compilation time (clear to anyone who does some
> profiling of LLVM) but it isn't that big.  The big advantage is that memory
> management is easy - so easy that I suspect many LLVM users never thought
> about the design choices (and trade-offs) that make it possible.

Having the def-use links always available is amore a feature than a
disadvantage IMO, together with the (implicit) coding style that comes
along with it. Especially for LLVM beginners, navigating through
instructions and changing them is very simple. It provides people with
an easy way to learn about LLVM because one just has to remember the
def-use and contained-in relationships (module - function/globals -
instruction(/argument)), and then one can learn about new kinds of
instructions etc. on demand when one actually needs to. But the basic
means of navigating are the same (and mostly the same function names
etc. IIRC), irrespective of whether one is going from a module to a
function or from a function to an instruction.

Torvald

Re: adding destroyable objects into Ggc

[Jonathan Wakely]

On 20 October 2011 12:56, Basile Starynkevitch wrote:
>
> (amongst those advocating C++ smart or whatever _ptr-s)

Please stop saying "smart or whatever _ptr-s" - the term "smart
pointer" has a commonly accepted meaning and is well understood.  It's
a generic term, it doesn't refer to a particular smart_ptr class.

Your repeated use of that phrasing is as silly as referring to MELT as
a "gcc plug or whatever in"



> explained how he believes the current GCC GTY-ed representations (like tree,
> gimple, gimple_seq, edge, loop-s...) could be re-implemented in C++ using
> C++ tricks without Ggc, and what could be the transition from the current
> state of GCC to such a future state (C++--full, but Ggc-less) of GCC.

The fact noone has done it yet, or explained it in detail, doesn't
mean it can't happen.


> I might be grossly wrong, but nobody explained -with concrete examples- us
> how the current major GCC representations could be done inside GCC with C++
> but without Ggc. For instance, nobody explained what an hypothetical class
> Gimple or class Gimple_Seq could be.

Well you haven't showed concrete examples of your C++-friendly Ggc
either (your suggested code wasn't valid C++).  Does that mean we
should be sceptical and doubt your suggestion is possible?

Why assume that the current major GCC representation have to remain
the same?  Maybe they will need to be modified.

Re: adding destroyable objects into Ggc

[Richard Guenther]

On Thu, Oct 20, 2011 at 4:52 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 20 October 2011 12:56, Basile Starynkevitch wrote:
>>
>> (amongst those advocating C++ smart or whatever _ptr-s)
>
> Please stop saying "smart or whatever _ptr-s" - the term "smart
> pointer" has a commonly accepted meaning and is well understood.  It's
> a generic term, it doesn't refer to a particular smart_ptr class.
>
> Your repeated use of that phrasing is as silly as referring to MELT as
> a "gcc plug or whatever in"
>
>
>
>> explained how he believes the current GCC GTY-ed representations (like tree,
>> gimple, gimple_seq, edge, loop-s...) could be re-implemented in C++ using
>> C++ tricks without Ggc, and what could be the transition from the current
>> state of GCC to such a future state (C++--full, but Ggc-less) of GCC.
>
> The fact noone has done it yet, or explained it in detail, doesn't
> mean it can't happen.
>
>
>> I might be grossly wrong, but nobody explained -with concrete examples- us
>> how the current major GCC representations could be done inside GCC with C++
>> but without Ggc. For instance, nobody explained what an hypothetical class
>> Gimple or class Gimple_Seq could be.

But we talked about it and arrived at a suitable solution for the how-to-do
GTY with C++ issue.

Richard.

Re: adding destroyable objects into Ggc

[Marc Glisse]

On Thu, 20 Oct 2011, Basile Starynkevitch wrote:

> Suppose someone is coding a new plugin, which adds several passes to GCC (so
> need the data to be managed by Ggc, because it is not internal to one single
> pass.). Suppose the plugin is coded in C++, and that it uses some standard
> C++ collection (e.g. std::vector or std::map) of C++ objects mixing pointers
> to GTY-ed data (e.g. gimple) and PPL instances (in C++). The data used by
> the plugin would better be GTY-ed. And it points to both GTY-ed & PPL data,
> so need to be finalized.

Can't you use GTY-ed memory in PPL? Sorry for the naive question, but 
std::vector can take an allocator parameter, gmp lets you specify an 
allocation function...

(note that I have never looked at Ggc so my question may be off...)

-- 
Marc Glisse

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Thu, 20 Oct 2011 15:52:25 +0100
Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> 
> Well you haven't showed concrete examples of your C++-friendly Ggc
> either (your suggested code wasn't valid C++).  


From the C++ side, it probably will be just an operator new, perhaps something as simple
as (untested code):

  class ggc_new {}; // an empty class
  extern ggc_new the_ggc_new;

  void* operator new (ggc_new);
  #define new_ggc new(the_ggc_new)

So to allocate a GTY-ed instance of a class Foo, we might have, assuming we have defined:
  class GTY((...)) Foo { ... };
we would code
   new_ggc Foo (...)

with the important convention that data allocated with with new_ggc should never be
explicitly deleted, except implicitly by the Ggc garbage collector, and that its
destructor should not allocate Ggc data.

Does the above description answers your question?

(I'm not sure to have time implement that, and I'm not sure of the details)

Cheers.

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

Re: adding destroyable objects into Ggc

[Jonathan Wakely]

On 20 October 2011 16:41, Basile Starynkevitch wrote:
>
> Does the above description answers your question?

I didn't ask a question.  I pointed out that your criticism of "no
concrete examples" applies to your proposal too.  It still does.

> (I'm not sure to have time implement that, and I'm not sure of the details)

Why is that any different to the people saying adding C++ support to
ggc is not necessary?

They haven't had time to implement it yet, and may not be sure of the
details yet.

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Thu, 20 Oct 2011 17:13:46 +0200 (CEST)
Marc Glisse <marc.glisse@inria.fr> wrote:

> Can't you use GTY-ed memory in PPL? Sorry for the naive question, but 
> std::vector can take an allocator parameter, gmp lets you specify an 
> allocation function...


I believe that the PPL C++ code don't have any kind of allocator parameters.

But I am not sure it would help. Let's take just a std::string allocated with an
allocator that would use Ggc-ed memory, and appearing inside a GTY-ed data. 
How that Ggc-ed memory used for the string will be marked, and how will it be released?

The usual way to release memory allocated by Ggc is inside ggc_collect (e.g. by
sweep_pages) and that happens when the object has not been marked (because Ggc is a
precise mark&sweep collector).

And because C++ collections don't offer (AFAIK) any support to scan all their internal
data (so if std::string implementation actually contains a pointer to some internal
buffer which would have been Ggc-allocated because the string has been created using
our putative Ggc C++ allocator) it seems to me that the only way to make it work is to
have the C++ destructor of our std::string called from inside Ggc. This is what I call
finalized objects (or destroyable objects) inside Ggc.

Or did I not understood something about your question?

Cheers  

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

Re: adding destroyable objects into Ggc

[Marc Glisse]

On Fri, 21 Oct 2011, Basile Starynkevitch wrote:

[explanations about the limitations of ggc]
> Or did I not understood something about your question?

No, it is just that I didn't know the limitations of ggc and was thinking 
of more general garbage collectors, where this is not an issue. Thanks for 
bearing with my questions.

-- 
Marc Glisse

Re: adding destroyable objects into Ggc

[Richard Guenther]

On Fri, Oct 21, 2011 at 8:09 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Thu, 20 Oct 2011 17:13:46 +0200 (CEST)
> Marc Glisse <marc.glisse@inria.fr> wrote:
>
>> Can't you use GTY-ed memory in PPL? Sorry for the naive question, but
>> std::vector can take an allocator parameter, gmp lets you specify an
>> allocation function...
>
>
> I believe that the PPL C++ code don't have any kind of allocator parameters.
>
> But I am not sure it would help. Let's take just a std::string allocated with an
> allocator that would use Ggc-ed memory, and appearing inside a GTY-ed data.
> How that Ggc-ed memory used for the string will be marked, and how will it be released?
>
> The usual way to release memory allocated by Ggc is inside ggc_collect (e.g. by
> sweep_pages) and that happens when the object has not been marked (because Ggc is a
> precise mark&sweep collector).
>
> And because C++ collections don't offer (AFAIK) any support to scan all their internal
> data (so if std::string implementation actually contains a pointer to some internal
> buffer which would have been Ggc-allocated because the string has been created using
> our putative Ggc C++ allocator) it seems to me that the only way to make it work is to
> have the C++ destructor of our std::string called from inside Ggc. This is what I call
> finalized objects (or destroyable objects) inside Ggc.

Nor do C collections, thus we explicitely have code that deals with this
(auto-generated from gengtype).  For C++ this can get slightly more elegant
by

template <class T>
class GgcWalk { void walk(void) { /* By default nothing */ }; }

and providing specializations for each container you want to track in GC memory.

That specializations could in turn be autogenerated by gengtype or explicitly
written.

So there is no inherent limitation with the GGC machinery.

> Or did I not understood something about your question?
>
> Cheers
>
> --
> 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} ***
>

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Fri, 21 Oct 2011 10:43:29 +0200
Richard Guenther <richard.guenther@gmail.com> wrote:
> So there is no inherent limitation with the GGC machinery.

There are at least some annoyances:

If a C++ class is GTY-ed, or is pointed by a field inside a GTY-ed struct, and if
that class contains for example a PPL data (or simply if a GTY-ed struct contains a PPL
data) we need to have the PPL destuctor invoked when Ggc release the struct.

To be more specific, if you want to associate trees with PPL coefficients (in a way
visible to several passes, so using Ggc), you will declare in C 

struct GTY (()) treewithcoef_st {
    tree tr;
    ppl_Coefficient_t co;
};

it will leak, because <ppl_c.h> requires that when the field co is no more useful, it
should be released with 
  ppl_delete_Coefficient (p->co);
[since actually ppl_Coefficient_t is an opaque non null pointer to some C++ class of PPL]

and, assuming the struct treewithcoef_st is used in several passes, the sure way to know
when to delete is is thru the Ggc collector (if we always knew when exactly to destroy our
treewithcoef_st we won't use GTY on them). Si you want the Ggc collector to call
ppl_delete_Coefficient, and there is no simple way to do that today.

There is however a contrived way (used inside MELT), thru the plugin hooks: manage the
set of such struct treewithcoef_st (perhaps in a linked list, or an hash table, or a VEC,
or whatever), and
  use the PLUGIN_GGC_START & PLUGIN_GGC_MARKING event, possibly also PLUGIN_GGC_END
  add the GTY((mark_hook("some_marking_hook_for_treewithcoef")) gengtype annotation 
  to struct treewithcoef_st
at the PLUGIN_GGC_END event, scan this collection of struct treewithcoef_st and call
ppl_delete_Coefficient on approriate elements.

With finalizer inside Ggc, we could make that much simpler & more efficient (because the
PLUGIN_GGC_* tricks essentially reimplement a mark & sweep collector for our struct
treewithcoef_st): we could allocate our struct treewithcoef_st by giving a finalizer for
them which calls ppl_delete_Coefficient (p->co)

and later we could even enhance gengtype to be able at least to give the finalizer, or
even to support C++ objects with non-trivial destructors.

And indeed, using PPL data shared between several passes is my main motivation.

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

Re: adding destroyable objects into Ggc

[Gabriel Dos Reis]

On Fri, Oct 21, 2011 at 3:56 PM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Fri, 21 Oct 2011 10:43:29 +0200
> Richard Guenther <richard.guenther@gmail.com> wrote:
>> So there is no inherent limitation with the GGC machinery.
>
> There are at least some annoyances:

can you think of C++ ways to remove those without prescribing more GC?

Re: adding destroyable objects into Ggc

[Basile Starynkevitch]

On Fri, 21 Oct 2011 18:53:16 -0500
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> On Fri, Oct 21, 2011 at 3:56 PM, Basile Starynkevitch
> <basile@starynkevitch.net> wrote:
> > On Fri, 21 Oct 2011 10:43:29 +0200
> > Richard Guenther <richard.guenther@gmail.com> wrote:
> >> So there is no inherent limitation with the GGC machinery.
> >
> > There are at least some annoyances:
> 
> can you think of C++ ways to remove those without prescribing more GC?

I don't have enough knowledge and practice of C++ for that.

I am expecting C++ gurus to explain how they'll do.

And I strongly believe that a garbage collector is an asset in a compiler, not an
annoyance.  My belief is that, if Ggc has some weaknesses, it could be improved, and not
avoided.  Because my belief is that a good garbage collector solve some *global* issues
inside a big program like GCC.  [I would probably agree with the fact that Ggc might not
be good enough and need improvements, but most GCC people don't think this way, and try to
avoid Ggc. And improving Ggc probably requires the cooperation of the entire GCC commnity,
because it impacts the way people will code inside GCC.].

Cheers.


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

Re: adding destroyable objects into Ggc

[Richard Guenther]

On Fri, Oct 21, 2011 at 10:56 PM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Fri, 21 Oct 2011 10:43:29 +0200
> Richard Guenther <richard.guenther@gmail.com> wrote:
>> So there is no inherent limitation with the GGC machinery.
>
> There are at least some annoyances:
>
> If a C++ class is GTY-ed, or is pointed by a field inside a GTY-ed struct, and if
> that class contains for example a PPL data (or simply if a GTY-ed struct contains a PPL
> data) we need to have the PPL destuctor invoked when Ggc release the struct.

Same as in C.  If you have a pointer to malloc() memory in a GTY-ed
struct it will leak.
Which is why in the GTY world there is a dont-do-that rule, instead
you need to put
your malloc memory in GC space, too.

Thus, not a C++ limitation, but a general issue with mixing GC and
non-GC things.

Now complicated things more and make the malloc region point to GC memory again
and you'll see why generally mixing GC/non-GC things isn't the very best idea.

> To be more specific, if you want to associate trees with PPL coefficients (in a way
> visible to several passes, so using Ggc), you will declare in C
>
> struct GTY (()) treewithcoef_st {
>    tree tr;
>    ppl_Coefficient_t co;
> };
>
> it will leak, because <ppl_c.h> requires that when the field co is no more useful, it
> should be released with
>  ppl_delete_Coefficient (p->co);
> [since actually ppl_Coefficient_t is an opaque non null pointer to some C++ class of PPL]

Don't do that then.

Richard.