-----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 <ja...@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-----
