[gc-improv] Permanent vs function RTL obstack fix

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/12/11 05:54, Bernd Schmidt wrote:
> On 04/11/2011 10:03 PM, Jeff Law wrote:
>> One of the fundamental problems you have to watch out for when dealing
>> with scratch objects is how to handle the case when you belatedly
>> realize you want the object to have a longer lifetime.
> 
> Historically, our problems with obstacks were a consequence of
> line-by-line processing of the input file and never being quite certain
> where a given object would have to end up.
That was certainly the cause of the bulk of the problems.  And to be
honest, the multi-obstack design made sense when it was written,
assuming one could keep track of which obstack was the right one to use.
 As we wanted to solve new problems, the obstack approach really fell apart.

Also note that trees were a *much* bigger problem than RTL WRT memory
management.  That's not to say there weren't any RTL problems, but that
we ran into far more problems with tree allocations.


 Almost all of that is simply
> no longer an issue, which means RTL memory management is conceptually a
> lot simpler than it used to be. 
In some respects, yes, memory management in general is conceptually a
hell of a lot simpler.  I'll note that some of the simplifications came
as a side effect of moving to GC allocation, but aren't inherent to
using GC allocation.  For example, removal of storing RTL into tree
structures without a suitable union :-)

In other respects I think memory management has become more difficult,
at least to change because usage of GC has allowed us to allocate and
mostly forget.  One can certainly argue that model has problems, but I
would claim the problems with allocate and forget were smaller than the
problems we had with explicit management via obstacks.



A few things (constants, mostly) are
> shared and must be permanent, the rest can go a single per-function
> obstack which is freed after every function. I don't think we should (or
> need to) try to have more obstacks for RTL.
To have two obstacks for RTL, you really have to have a bright line that
everyone knows and understands and that you can codify as well so that
things like deep copying can DTRT.  If you can't codify it for a deep
copy, then, IMHO, it's a non-starter.  Also note that having
verification capabilities helps considerably.  You also need rules for
if/when/how a single RTL object might validly reference RTL objects with
differing lifetimes.



> 
> I also don't see why a deep copy to the permanent obstack would be a
> source of problems these days.
For RTL, the biggest problem is making sure you do the right thing with
RTL that is expected to be unique & shared (trees are much more
difficult), which as you note is primarily going to be constants and the
like.



 More common than wanting to do that
> however is the opposite case where you can speculatively generate RTL on
> the function obstack, see if it's valid, and if not reset the obstack to
> the earlier point to reclaim the memory. I know that reload and combine
> could be made more efficient this way, and I'd guess the same is true
> for fwprop.
There are definitely things that obstacks handle well, I won't dispute that.


> 
> I'd also like to point out that I share Steven's experience that the GC
> stuff doesn't "just work"; I've certainly had objects collected from
> under me and needed to puzzle out where to sprinkle the necessary GTY
> markers.
In my experience, I've seen far fewer allocation mistakes with the GC
system than with the multi-obstack system we had prior to the
introduction of GC.  Neither is going to be 100% perfect as programmers
can certainly goof things up.  The question is which is easier to deal
with in the general case and I'd say GC wins by a wide margin.  Of
course, that comes with a penalty (performance), thus I'm open to
exploring what objects really need to be part of the GC system and which
can be handled by other allocation schemes such as obstacks.

jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNpHAeAAoJEBRtltQi2kC7HpQIAIchzQ/uBei7FaIJIbOK7dFn
kOey7eqhySdb1WTY4mMKfPPRrqD9rCfR1PPftH/x4250lRMLTKgN3WvCtUmSef8o
tAM4hwViadQUvOlJPjIve3VqNg2fV6CmG/mtnChuwAknsUe7z/xm+C+J6lPd0Mts
LWOqya+JGYrGVuSP9+BdANEVUM4mkoWaZ2pXOzml7pkvW2JQBloaJLlyN7lobShQ
Kw2wTnpzVlnyeCT8Ow8AVHk1Yw4osZkKmN5VrjRmGaKaOtl2CeQk+LODFmHp+YrE
Jkc/YTNtYev6Pt30QfE26qylcjWqJte3me0Ux5J8KR5fxNc2NFz+Vs20m6zy+M4=
=q93W
-----END PGP SIGNATURE-----