From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7780 invoked by alias); 12 Apr 2011 15:31:02 -0000 Received: (qmail 7768 invoked by uid 22791); 12 Apr 2011 15:31:01 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Apr 2011 15:30:48 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p3CFUfGq007221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 11:30:41 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p3CFUeHv015162; Tue, 12 Apr 2011 11:30:40 -0400 Received: from [10.3.113.84] (ovpn-113-84.phx2.redhat.com [10.3.113.84]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p3CFUcRb026401; Tue, 12 Apr 2011 11:30:39 -0400 Message-ID: <4DA4701E.8060900@redhat.com> Date: Tue, 12 Apr 2011 15:31:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Bernd Schmidt CC: Laurynas Biveinis , Steven Bosscher , gcc-patches@gcc.gnu.org Subject: Re: [gc-improv] Permanent vs function RTL obstack fix References: <4D9D56F4.3050203@gmail.com> <4D9F1D63.9010509@redhat.com> <4DA35E74.1020506@redhat.com> <4DA43D74.6080703@codesourcery.com> In-Reply-To: <4DA43D74.6080703@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg00903.txt.bz2 -----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-----