Re: RFC - Alternatives to gengtype

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Nov 28, 2012 at 12:48 AM, Diego Novillo <dnovillo@google.com> wrote:
> On Tue, Nov 27, 2012 at 6:20 PM, Jeff Law <law@redhat.com> 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 thinking of a permanent pool,
>>> per-pass pools and at least one or two stage-based pools (e.g., front
>>> ends).  We may be able to have some implemented for the 4.9 release.
>>
>> By far the most important aspect of this is defining your pools and their
>> lifetimes properly.   If you're not careful, this will end up like the old
>> obstack mess we had in the past.
>
> Right.  That's why we want to be very conservative in this plan.  We
> want to be able to move data structures incrementally and keep the
> current GC mechanism working at the same time.  We would only merge
> back into trunk once we have a solid transition.

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 necessary) is because our GC isn't exactly using technology known
for 25 years (generational and copying collection come to my mind).

So - I don't want to discourage your work but I think the cycles
trying to "remove"
GC are better spent elsewhere.  For example in solving real problems,
like debug info for LTO.

Thanks anyway,
Richard.