> I don't think there is a direct relationship, actually. Other, easier
> to maintain compilers, are quite happy without a GC. I do agree,
> however, that a bad memory management system leads to maintainability
> issues. We definitely do not want to fall into the obstack nightmare.
I agree comp
On Wed, Nov 28, 2012 at 5:30 AM, Richard Biener
wrote:
> Note that I don't think that non-GC is inherently better than GC. In fact,
> using a GC leads to easier maintainable code.
I don't think there is a direct relationship, actually. Other, easier
to maintain compilers, are quite happy witho
On Wed, Nov 28, 2012 at 11:54 AM, Basile Starynkevitch
wrote:
> On Wed, Nov 28, 2012 at 11:30:32AM +0100, Richard Biener wrote:
>>
>> Note that I don't think that non-GC is inherently better than GC. In fact,
>> using a GC leads to easier maintainable code. The fact that we are more
>> memory hu
On Wed, Nov 28, 2012 at 11:30:32AM +0100, Richard Biener wrote:
>
> Note that I don't think that non-GC is inherently better than GC. In fact,
> using a GC leads to easier maintainable code. The fact that we are more
> memory hungry than necessary (and also maybe consume more compile-time
> than
On Wed, Nov 28, 2012 at 12:48 AM, Diego Novillo wrote:
> On Tue, Nov 27, 2012 at 6:20 PM, Jeff Law wrote:
>> On 11/27/2012 03:51 PM, Diego Novillo wrote:
* Start implementing memory pools for data structures that do not need
>>>
>>> to be in PCH images. It is still not clear what types
On Tue, Nov 27, 2012 at 6:20 PM, Jeff Law wrote:
> On 11/27/2012 03:51 PM, Diego Novillo wrote:
>>>
>>> * Start implementing memory pools for data structures that do not need
>>
>> to be in PCH images. It is still not clear what types of memory pools
>> we will need, but at a minimum we are think
On 11/27/2012 03:51 PM, Diego Novillo wrote:
* Start implementing memory pools for data structures that do not need
to be in PCH images. It is still not clear what types of memory pools
we will need, but at a minimum we are thinking of a permanent pool,
per-pass pools and at least one or two st
As a follow up to our proposal to improve memory management in the
compiler, we plan to proceed in two parts:
* A transition plan to quickly remove gengtype out of the picture.
This has become the main blocker for several C++ cleanups. The
transition here is to move all the GTY() structures to us
On Sun, Nov 25, 2012 at 10:45 AM, Richard Biener
wrote:
> On Sun, Nov 25, 2012 at 4:21 PM, Diego Novillo wrote:
>> On Sun, Nov 25, 2012 at 10:09 AM, Richard Biener
>> wrote:
>>
>>> I'd say the most pragmatic solution is to stick with gengtype but
>>> make it more dependent on annotations (thus,
On Sun, Nov 25, 2012 at 7:45 AM, Richard Biener
wrote:
> On Sun, Nov 25, 2012 at 4:21 PM, Diego Novillo wrote:
>> On Sun, Nov 25, 2012 at 10:09 AM, Richard Biener
>> wrote:
>>
>>> I'd say the most pragmatic solution is to stick with gengtype but
>>> make it more dependent on annotations (thus, e
On Sun, Nov 25, 2012 at 4:21 PM, Diego Novillo wrote:
> On Sun, Nov 25, 2012 at 10:09 AM, Richard Biener
> wrote:
>
>> I'd say the most pragmatic solution is to stick with gengtype but
>> make it more dependent on annotations (thus, explicit). That is,
>
> Yes. That is the direction in which I'
On Sun, Nov 25, 2012 at 10:09 AM, Richard Biener
wrote:
> I'd say the most pragmatic solution is to stick with gengtype but
> make it more dependent on annotations (thus, explicit). That is,
Yes. That is the direction in which I've been leaning towards. My
preference is to transitionally move
On Fri, Nov 16, 2012 at 1:59 AM, Diego Novillo wrote:
> As we continue adding new C++ features in the compiler, gengtype
> is becoming an increasing source of pain. In this proposal, we
> want to explore different approaches to GC that we could
> implement.
>
> At this point, we are trying to rea
Thanks for all the responses.
I have created a wiki page to track this proposal:
http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives
It is also indexed from the main improvements wiki:
http://gcc.gnu.org/wiki/ImprovementProjects
Given the number of choices we have in this proposal, I've added
On 11/23/2012 11:17 AM, Joern Rennecke wrote:
How about we require that in general, use of raw pointers to GC-able
objects
are banned, and instead we require the use of a class (maybe obtained by
template?) that is a pointer to the GC-able object, with a
special copy-constructor. The copy-const
Quoting Joern Rennecke :
P.S.:
If we need more than one operation, or mark-things-live when copying
during normal operation causes too much overhead, we could select
operations
to be performed by the copy constructor by adjusting some global state
(need not literally be a global variable - it mi
Quoting Florian Weimer :
On 11/18/2012 07:06 PM, NightStrike wrote:
What's wrong with std::shared_ptr?
The pointer needs two words, and the per-object overhead for the
reference counts etc. is four words, if I'm counting correctly.
(Other forms of reference counting have less overhead, of c
On 11/23/2012 10:45 AM, Jonathan Wakely wrote:
Actually, this observation may favor a real garbage collector. Marking GC as
simple as ggc+gengtype usually have one (or a few) mark bits, so can consume
only a few bits (or perhaps a byte in some mark array) per object. Copying
GC could avoid consu
On 23/11/2012, Basile Starynkevitch wrote:
> On Thu, Nov 22, 2012 at 09:29:43PM +0100, Florian Weimer wrote:
>> On 11/18/2012 07:06 PM, NightStrike wrote:
>>
>> >What's wrong with std::shared_ptr?
>>
>> The pointer needs two words, and the per-object overhead for the
>> reference counts etc. is fo
On Thu, Nov 22, 2012 at 09:29:43PM +0100, Florian Weimer wrote:
> On 11/18/2012 07:06 PM, NightStrike wrote:
>
> >What's wrong with std::shared_ptr?
>
> The pointer needs two words, and the per-object overhead for the
> reference counts etc. is four words, if I'm counting correctly.
>
> (Other f
On 11/18/2012 07:06 PM, NightStrike wrote:
What's wrong with std::shared_ptr?
The pointer needs two words, and the per-object overhead for the
reference counts etc. is four words, if I'm counting correctly.
(Other forms of reference counting have less overhead, of course, but
you were aski
Count another vote for getting rid of GC.
Bernd
(sorry for breaking threads... re.
http://gcc.gnu.org/ml/gcc/2012-11/msg00304.html)
On Tue, 20 Nov 2012 09:57:35 +0100, Eric Botcazou wrote:
> > I wouldn't jump to that conclusion too quickly.I think we should be
> > GC free as well, and I doubt I am the only other one.
>
> Dropping the GC mea
> I wouldn't jump to that conclusion too quickly.I think we should be
> GC free as well, and I doubt I am the only other one.
Dropping the GC means re-introducing a whole class of bugs though. Are we
ready to divert a possibly significant part of our time to fixing memory
management bugs ag
On Tuesday 20 November 2012 10:30 AM, Miles Bader wrote:
Basile Starynkevitch writes:
PS. LLVM has also a decisive documentation advantage w.r.t. GCC
What...? The last time I tried to do something with LLVM, the
internals docs were awful (full of kinda stuff,
usually just in the area I wa
Basile Starynkevitch writes:
> PS. LLVM has also a decisive documentation advantage w.r.t. GCC
What...? The last time I tried to do something with LLVM, the
internals docs were awful (full of kinda stuff,
usually just in the area I was confused about)... and gcc
historically has had great inte
On 11/19/2012 08:24 PM, Lawrence Crowl wrote:
On 11/16/12, Diego Novillo wrote:
On Nov 16, 2012 Basile Starynkevitch wrote:
I actually disagree with the "Get rid of GC" idea, but I am not
sure that we all understand the same thing about it (and I have
the feeling of the opposite). I would pro
On Mon, 19 Nov 2012, Lawrence Crowl wrote:
> On 11/17/12, Hans-Peter Nilsson wrote:
> > On Thu, 15 Nov 2012, Diego Novillo wrote:
> > > === Approach: Move GTY to cc1plus.
> > >
> > > Instead of a separate weak parser, we would make cc1plus
> > > understand GTY attributes. The compiler would emit
On 11/16/12, Diego Novillo wrote:
> On Nov 16, 2012 Basile Starynkevitch wrote:
> > I actually disagree with the "Get rid of GC" idea, but I am not
> > sure that we all understand the same thing about it (and I have
> > the feeling of the opposite). I would probably agree with "Get
> > rid of Gen
On 11/17/12, Hans-Peter Nilsson wrote:
> On Thu, 15 Nov 2012, Diego Novillo wrote:
> > === Approach: Move GTY to cc1plus.
> >
> > Instead of a separate weak parser, we would make cc1plus
> > understand GTY attributes. The compiler would emit IL in the
> > object files instead of generating source
On 19 November 2012 19:35, Basile Starynkevitch wrote:
> On Sun, Nov 18, 2012 at 06:37:29PM +, Jonathan Wakely wrote:
>> On 18 November 2012 18:25, Basile Starynkevitch wrote:
>> > On Sun, Nov 18, 2012 at 08:06:08AM -1000, NightStrike wrote:
>> >> On Sun, Nov 18, 2012 at 8:03 AM, Basile Starynk
On Sun, Nov 18, 2012 at 06:37:29PM +, Jonathan Wakely wrote:
> On 18 November 2012 18:25, Basile Starynkevitch wrote:
> > On Sun, Nov 18, 2012 at 08:06:08AM -1000, NightStrike wrote:
> >> On Sun, Nov 18, 2012 at 8:03 AM, Basile Starynkevitch
> >> wrote:
> >> > I really think that GCC need some
On 18 November 2012 18:25, Basile Starynkevitch wrote:
> On Sun, Nov 18, 2012 at 08:06:08AM -1000, NightStrike wrote:
>> On Sun, Nov 18, 2012 at 8:03 AM, Basile Starynkevitch
>> wrote:
>> > I really think that GCC need some form of garbage collector.
> [...]
>>
>> What's wrong with std::shared_ptr
On 18 November 2012 18:03, Basile Starynkevitch wrote:
> Regarding PCH [pre-compiled header], I think that it is related to PPH
> [pre-processed headers]
>
> I don't understand yet if PPH is abandoned, or just post-poned. I was
> believing it was a very mature experimental branch.
See http://gcc.g
On Sun, Nov 18, 2012 at 08:06:08AM -1000, NightStrike wrote:
> On Sun, Nov 18, 2012 at 8:03 AM, Basile Starynkevitch
> wrote:
> > I really think that GCC need some form of garbage collector.
[...]
>
> What's wrong with std::shared_ptr?
How does it deal with complex circular references that every
On Sun, Nov 18, 2012 at 8:03 AM, Basile Starynkevitch
wrote:
> I really think that GCC need some form of garbage collector.
> If it is Ggc+gengtype (to be improved), or Boehm GC, or even
> some other GC (for instance both
> http://starynkevitch.net/Basile/qishintro.html and
> http://gcc.gnu.org/vi
On Sun, Nov 18, 2012 at 11:25:55AM -0500, Diego Novillo wrote:
> I agree with the analysis of Uday and Basile. [...]
>
> However, let's discuss this topic in some other thread, please. I'd
> like to take this thread back to the original topic: what do we do
> with GC and PCH?
I really think tha
I agree with the analysis of Uday and Basile. In my view, competition
from Clang and LLVM is probably the best thing that could've happened
to a compiler that was in danger of becoming fat, lazy and complacent.
Simplifying the code base for new contributors and increased
maintainability are the ma
On Sat, Nov 17, 2012 at 1:33 PM, Xinliang David Li wrote:
> My main point is that other main open source compilers like
> clang/llvm, open64 and some main commercial compilers I know do not
> use GC, which proves that GC is not a must for a compiler to be easy
> to work with or to be a good open
On Sat, Nov 17, 2012 at 12:35 AM, Basile Starynkevitch
wrote:
> On Fri, Nov 16, 2012 at 07:44:12PM -0800, Xinliang David Li wrote:
>> >
>> >
>> > My strong belief is that a compiler project as gigantic as GCC needs some
>> > kind
>> > of garbage collection
>>
>> Can you name another compiler writ
I wrote some time ago:
On Saturday 17 November 2012 09:12 PM, Uday Khedker wrote:
On Saturday 17 November 2012 08:34 PM, Basile Starynkevitch wrote:
On Sat, Nov 17, 2012 at 07:03:33AM -0500, Richard Kenner wrote:
First, C or C++ is not the best language to write a compiler in,
It is my s
On Saturday 17 November 2012 08:34 PM, Basile Starynkevitch wrote:
On Sat, Nov 17, 2012 at 07:03:33AM -0500, Richard Kenner wrote:
First, C or C++ is not the best language to write a compiler in,
It is my strong opinion that the best language to write a compiler in is
the language that it i
On Sat, Nov 17, 2012 at 07:03:33AM -0500, Richard Kenner wrote:
> > First, C or C++ is not the best language to write a compiler in,
>
> It is my strong opinion that the best language to write a compiler in is
> the language that it is compiling (or the primary language in the case
> of a multi-l
> First, C or C++ is not the best language to write a compiler in,
It is my strong opinion that the best language to write a compiler in is
the language that it is compiling (or the primary language in the case
of a multi-language compiler like GCC).
On Thu, 15 Nov 2012, Diego Novillo wrote:
> === Approach: Move GTY to cc1plus.
>
> Instead of a separate weak parser, we would make cc1plus
> understand GTY attributes. The compiler would emit IL in the
> object files instead of generating source.
>
> This solution would require a first boot stage
On Fri, Nov 16, 2012 at 07:44:12PM -0800, Xinliang David Li wrote:
> >
> >
> > My strong belief is that a compiler project as gigantic as GCC needs some
> > kind
> > of garbage collection
>
> Can you name another compiler written in C/C++ using GC ? :)
First, C or C++ is not the best language to
>
>
> My strong belief is that a compiler project as gigantic as GCC needs some kind
> of garbage collection
Can you name another compiler written in C/C++ using GC ? :)
>. I also believe that the current (4.7) garbage
> collection *implementation* (which is probably what both Diego and
> Lawrenc
On Fri, Nov 16, 2012 at 9:42 AM, Andrew MacLeod wrote:
> PS I'd also prefer the term 'memory pool' or something... the term 'obstack'
> still makes my skin crawl :-)
Amen.
-- Gaby, old enough to remember the obstack days
On 11/15/2012 07:59 PM, Diego Novillo wrote:
At this point, we are trying to reach consensus on the general
direction that we should take. Given how intertwined GC and PCH
are, the choices we make for one affect the other.
We don't have a strong preference at the moment, but we are
leaning in
On Fri, Nov 16, 2012 at 2:06 AM, Basile Starynkevitch
wrote:
>
> My strong belief is that a compiler project as gigantic as GCC needs some kind
> of garbage collection.
I suspect that is correct, especially given the way the compiler is
currently implemented. But I also suspect that we could use
On Fri, Nov 16, 2012 at 5:06 AM, Basile Starynkevitch
wrote:
> On Thu, Nov 15, 2012 at 07:59:36PM -0500, Diego Novillo wrote:
>> As we continue adding new C++ features in the compiler, gengtype
>> is becoming an increasing source of pain. In this proposal, we
>> want to explore different approach
Diego Novillo wrote:
> === Approach: Move GTY to cc1plus.
>
> Instead of a separate weak parser, we would make cc1plus understand GTY
> attributes. The compiler would emit IL in the object files instead of
> generating source.
Does this mean GTY is implemented as a C++ language extension and th
Basile Starynkevitch wrote, On Friday 16 November 2012 03:36 PM:
To be more specific, I call garbage collection a scheme where (small newbie)
GCC contributors
can contribute easily some code to GCC without having to understand when, and
how precisely,
some data will be freed. If a user adds
> === Approach: Use the Boehm collector.
>
> The general approach is to define allocation and deallocation
> functions to the Boehm collector that handle memory within the
> PCH range. We would also provide a class to register global
> roots at the point of declaration of those roots. We would lik
On Thu, Nov 15, 2012 at 07:59:36PM -0500, Diego Novillo wrote:
> As we continue adding new C++ features in the compiler, gengtype
> is becoming an increasing source of pain. In this proposal, we
> want to explore different approaches to GC that we could
> implement.
Just a minor remark: we don't
As we continue adding new C++ features in the compiler, gengtype
is becoming an increasing source of pain. In this proposal, we
want to explore different approaches to GC that we could
implement.
At this point, we are trying to reach consensus on the general
direction that we should take. Given
56 matches
Mail list logo
