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

[Jeff Law <law@redhat.com>]

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

On 04/12/11 02:45, Steven Bosscher wrote:
> On Tue, Apr 12, 2011 at 9:01 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Tue, Apr 12, 2011 at 08:33:56AM +0200, Steven Bosscher wrote:
>>> I think all these comments from you "old guys" ;-) are more
>>> discouraging than fair. What Laurynas and Bernd have done, is nothing
>>
>> It is IMHO completely fair to point that the risks this brings in
>> a huge maintainance nightmare are very high.
> 
> And IM-equally-HO it is completely unfair to talk about risks in any
> situation where there is nothing yet to talk about! Give it a chance
> and wait for something that's more than just an idea, and then assess
> the risks based on an implementation.
Given that we've already got a goodly amount of experience with obstack
and GC based mechanisms for allocation, I think it is completely fair
and wise to discuss the known risk/reward for both.
> 
> Or just say "this won't fly" now so that people who would like to work
> on this can turn their attention to something else. Also fine. Really.
I have serious concerns about reverting to obstacks as our main memory
allocation approach for tree & rtl data.  However, I also realize that
there are objects where obstacks make sense and I realize some of those
objects may currently be hanging off tree or RTL structures.

With that in mind, I'm all for a critical examination of our data
structures, their lifetimes and what allocation model works best.  From
that I would expect that we'll find some cases where an obstack model
works better and the structures will move to that model.

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

iQEcBAEBAgAGBQJNpGmEAAoJEBRtltQi2kC7cjUIALtwCRbcsxABIx6xtWlZIHRy
vPfB8pc6u+IhIrbu/T2qZjUoP6bq5UQIgCPIy3o7qSgJ5Qd8NvYJQ5nMHMyPZvX2
MDzyTJcMB1OUsoZhgVwTdZoL1aSp3ARopruDM2DNc9zo8DXP5YFcn2w6bXaASjr5
jENRoiqTe6hLgJXQZT7QQObusR6gM4Off78Hs/vGlaOmeXMSONfMTxms1ya0ROQe
h+YyXpQuLsUDdIO9wSHfeD0/73er8fLYqlcJ77GPUDK907oVtr4bKUWOirwX9QL2
vRwMur93cVjPvHuNUPZdNxsrpozJH+G/iAIPJVa3K+AYXBvvzWtSpDHb4ttvy48=
=pN2J
-----END PGP SIGNATURE-----