On Wed, Nov 28, 2012 at 12:48 AM, Diego Novillo <dnovi...@google.com> wrote: > On Tue, Nov 27, 2012 at 6:20 PM, Jeff Law <l...@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.
