On Fri, Oct 21, 2011 at 10:56 PM, Basile Starynkevitch
wrote:
> On Fri, 21 Oct 2011 10:43:29 +0200
> Richard Guenther 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
On Fri, 21 Oct 2011 18:53:16 -0500
Gabriel Dos Reis wrote:
> On Fri, Oct 21, 2011 at 3:56 PM, Basile Starynkevitch
> wrote:
> > On Fri, 21 Oct 2011 10:43:29 +0200
> > Richard Guenther wrote:
> >> So there is no inherent limitation with the GGC machinery.
> >
> > There are at least some annoyanc
On Fri, Oct 21, 2011 at 3:56 PM, Basile Starynkevitch
wrote:
> On Fri, 21 Oct 2011 10:43:29 +0200
> Richard Guenther 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?
On Fri, 21 Oct 2011 10:43:29 +0200
Richard Guenther 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
On Fri, Oct 21, 2011 at 8:09 AM, Basile Starynkevitch
wrote:
> On Thu, 20 Oct 2011 17:13:46 +0200 (CEST)
> Marc Glisse 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..
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
On Thu, 20 Oct 2011 17:13:46 +0200 (CEST)
Marc Glisse 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
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
On Thu, 20 Oct 2011 15:52:25 +0100
Jonathan Wakely 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):
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.
On Thu, Oct 20, 2011 at 4:52 PM, Jonathan Wakely 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 u
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
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
>
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
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
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 y
On Thu, Oct 20, 2011 at 11:28:40AM +0300, Laurynas Biveinis wrote:
> 2011/10/19 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 ac
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 garba
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 that is, using a C API] comes to mind. If
you want to shar
Basile -
2011/10/19 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 manageme
On Thu, Oct 20, 2011 at 09:11:02AM +0200, Marc Glisse wrote:
> On Thu, 20 Oct 2011, Basile Starynkevitch wrote:
> >>Basile Starynkevitch
> >>>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.
On Thu, 20 Oct 2011, Basile Starynkevitch wrote:
On Wed, 19 Oct 2011 21:17:47 -0700
Lawrence Crowl wrote:
Basile Starynkevitch
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 c
On Wed, 19 Oct 2011 21:17:47 -0700
Lawrence Crowl wrote:
> Basile Starynkevitch
> > 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 briefl
Basile Starynkevitch
> 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
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
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
Basile -
2011/10/18 Basile Starynkevitch :
> 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 RT
On Wed, 2011-10-19 at 00:45 -0500, Gabriel Dos Reis wrote:
> On Wed, Oct 19, 2011 at 12:22 AM, Chiheng Xu wrote:
>
> > I recommend people interested in automatic dynamic memory management
> > to read this book:
> > Garbage Collection: Algorithms For Automatic Dynamic Memory
> > Management(Richard
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
On Wed, Oct 19, 2011 at 1:22 AM, Basile Starynkevitch
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 th
On Wed, 19 Oct 2011 01:16:03 -0500
Gabriel Dos Reis wrote:
> On Wed, Oct 19, 2011 at 1:00 AM, Basile Starynkevitch
> 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.
On Wed, Oct 19, 2011 at 1:00 AM, Basile Starynkevitch
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
c
On Wed, Oct 19, 2011 at 1:44 PM, Basile Starynkevitch
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,
On Wed, Oct 19, 2011 at 1:45 PM, Gabriel Dos Reis
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
> t
On Wed, 19 Oct 2011 00:45:58 -0500
Gabriel Dos Reis 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
On Wed, Oct 19, 2011 at 12:22 AM, Chiheng Xu 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 wh
On Wed, 19 Oct 2011 13:22:41 +0800
Chiheng Xu 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 impo
On Wed, Oct 19, 2011 at 1:13 AM, Basile Starynkevitch
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* compi
On 18 October 2011 21:52, Basile Starynkevitch wrote:
>
> I actually meant _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/
On Tue, 18 Oct 2011 14:42:34 -0500
Gabriel Dos Reis wrote:
> On Tue, Oct 18, 2011 at 12:41 PM, Basile Starynkevitch
> wrote:
>
> > However, I don't know very well auto_ptr.
>
> why do you believe you have to focus on auto_ptr?
I actually meant _ptr template C++ class.
I don't know them much.
On Tue, Oct 18, 2011 at 1:48 PM, Basile Starynkevitch
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
On Tue, Oct 18, 2011 at 1:03 PM, Basile Starynkevitch
wrote:
> On Tue, 18 Oct 2011 18:53:07 +0100
> Jonathan Wakely 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
>> > somethi
On Tue, Oct 18, 2011 at 12:50 PM, Ian Lance Taylor 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
> pro
On Tue, Oct 18, 2011 at 12:41 PM, Basile Starynkevitch
wrote:
> However, I don't know very well auto_ptr.
why do you believe you have to focus on auto_ptr?
On Tue, Oct 18, 2011 at 12:13 PM, Basile Starynkevitch
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 au
On Tue, 18 Oct 2011 19:39:03 +0100
Jonathan Wakely wrote:
> 3) the placement delete in 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 whateve
On 18 October 2011 19:03, Basile Starynkevitch wrote:
> On Tue, 18 Oct 2011 18:53:07 +0100
> Jonathan Wakely 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
On Tue, 18 Oct 2011 10:50:11 -0700
Ian Lance Taylor 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 t
On Tue, 18 Oct 2011 18:53:07 +0100
Jonathan Wakely 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)
> > { del
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
> C+
On Tue, Oct 18, 2011 at 10:41 AM, Basile Starynkevitch
wrote:
> On Tue, 18 Oct 2011 10:36:08 -0700
> Ian Lance Taylor wrote:
>
>> On Tue, Oct 18, 2011 at 10:13 AM, Basile Starynkevitch
>> wrote:
>> >
>> > Still, I find strange that while some very smart & nice GCC guys want to
>> > get rid of G
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,
On Tue, 18 Oct 2011 10:36:08 -0700
Ian Lance Taylor wrote:
> On Tue, Oct 18, 2011 at 10:13 AM, Basile Starynkevitch
> 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 di
On Tue, Oct 18, 2011 at 10:13 AM, Basile Starynkevitch
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.).
On Tue, 18 Oct 2011 09:35:16 -0700
Ian Lance Taylor 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 rely
On Tue, Oct 18, 2011 at 9:52 AM, Basile Starynkevitch
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 reas
On Tue, 18 Oct 2011 09:35:16 -0700
Ian Lance Taylor wrote:
> Basile Starynkevitch 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 li
On Tue, Oct 18, 2011 at 11:35 AM, Ian Lance Taylor 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 le
Basile Starynkevitch 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.
On Tue, 18 Oct 2011 17:19:56 +0200
Duncan Sands 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
> > briefl
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
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 f
62 matches
Mail list logo
