Re: [gc-improv] Permanent vs function RTL obstack fix

[Steven Bosscher <stevenb.gcc@gmail.com>]

On Tue, Apr 12, 2011 at 4:54 AM, Jeff Law <law@redhat.com> wrote:
> On 04/11/11 18:21, Mike Stump wrote:
>> On Apr 11, 2011, at 1:03 PM, Jeff Law wrote:
>>> The obvious solution is you copy the object, but then you have to be
>>> able to distinguish within the object, what fields point to other
>>> temporary objects vs permanent objects so that you can copy the
>>> referenced temporary objects, but not the permanent objects (other parts
>>> of the compiler may expect those permanent objects to be unique/shared).
>>>   Not fun, not at all fun.  Been there, done that.
>>
>> And then someone tells you that you can't copy...  Usually a nasty bug report much later.  So the choice is then, not solve a problem, or make everything permanent or add GC (back).  :-)  Been there, done that too.
> Right.  Hence the old hack to mark the temporary obstacks and make them
> permanent (wasting an enormous amount of space in the process).  I don't
> recall the name of that function, but it certainly made me barf.
>
> And yes, I remember all too well the problems with deep copying having
> written one of the earliest tree deep copy routines to support
> - -fcombine-statics .  It was the source of more problems than I could
> ever count -- all related to objects allocated to different obstacks
> hanging off a single tree node or objects of two different types being
> stored into the same field within tree nodes.  That was circa 1992/1993.
>
>
> These were the kind of problems that ultimately led to the GC system we
> have today.  There are clearly things that can be better handled with
> different allocation models and I'll support moving to better models
> where it makes sense.  Where it doesn't, obviously I won't support it.

I am unsure how to interpret that last sentence. Do you currently
believe that the approach of 2 or 3 obstacks for RTL is a better model
that makes sense, or not?

I think all these comments from you "old guys" ;-) are more
discouraging than fair. What Laurynas and Bernd have done, is nothing
like the old obstacks of GCC2. I am also a bit surprised that all
these fears only come up now that someone actually tries to do what
Zack already suggested in 2003, around the time that unit-at-a-time
compilation became the default mode.

Anyway, please do give this idea a chance at least. There is a big
difference between the pre-GC obstacks and what Laurynas is now trying
(not just in terms of memory management, but in the entire compilation
process!) and apart from the name "obstacks" this idea and the pre-GC
memory management in GCC have nothing in common.

Ciao!
Steven