This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Move loop structures to gc memory


On May 14, 2007, at 3:37 PM, Ian Lance Taylor wrote:
Why do we need the strategy of "GC with explicit death marking?" What goal does that serve?

I want it mostly for speed, a secondary concern would be for size reasons. Setting a variable to NULL_TREE doesn't help speed as much as ggc_free.



Except to work around a bug in our GC implementation? And in that case, why not fix the bug?

We look forward to your contribution. Until then and as long as size and speed are of concern, I think that things like skip and ggc_free can make sense in some cases. Any case where we get >%1 speedup, personally, I'm interested in. Personally, I'm willing to hit a few of the hard memory memory allocation problems caused by the attempted use of ggc_free in order to see a 20% speedup. Now, let me explain why. In the past, when you hit a hard memory problem, there was little to help you out on how and why, and even once you found it, some of them were simply impossible to fix short of permanently allocating things. With ggc_free, it is possible to fix any of these issues by removing ggc_free calls. This isn't too hard, and the penalty for doing this is generally less than permanently allocating things. In addition, I think it is possible to have ggc_free help out on what went wrong and why, in a way that is safer and more understandable than memory overwrites of yesteryear.


Sure managing memory is harder than not, sure you can have bugs. But I don't see GC a panacea. With infinite ram and/or infinite compile time, there is no reason to use ggc_free, ever. When either are limited, it can make sense.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]