[trunk r143197] patch adding optional extra marking to GGC

Basile STARYNKEVITCH basile@starynkevitch.net
Sun Jan 11 09:44:00 GMT 2009

Andrew Thomas Pinski wrote:
> On Jan 10, 2009, at 1:03 AM, Basile STARYNKEVITCH 
> <basile@starynkevitch.net> wrote:
>> Ian Lance Taylor wrote:
>>> Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
>>>> The idea is to add, for some peculiar users (I am explicitly thinking
>>>> of future plugin facilities), the ability to invoke a marking routine
>>>> on some data during GGC collection.
>> I forgot to insist that I am talking about calling the GGC collector 
>> from *inside* passes. It being called from the pass manager is ok for 
>> me, but there are situations where it is not enough. I repeat that my 
>> focus is the rare situations where invoking the GGC collector inside 
>> a pass is useful. I have no issues with the way it is called from the 
>> pass manager.
>>> This seems quite difficult to use correctly, and I think it would be
>>> quite a pain if all plugin authors have to get it right.
>> I really don't understand this argument. A plugin author who would 
>> need to call the proposed ggc_collect_extra_marking should by 
>> definition understand what it is doing. This is why I also documented 
>> it. Is my documentation not clear enough? Constructive comments 
>> welcome here (remember that I am not a native English speaker, and my 
>> english is poor).
>> The only way when my proposed ggc_collect_extra_marking gets called 
>> is when a pass explicitly calls it (I see no use of it outside 
>> passes' bodies). And the pass should then do it rightly.
>> If GGC is invoked outside passes (as is mostly the case today),
> IRCC cse and maybe loop.c used to call ggc_collect. Plus why use ggc 
> memory for pass local data? GC should be used when it is hard to 
> figure out the life time of an object. We already have too many 
> objects in gc memory that we know the life time of and that does not 
> point to other gc memory. 

In my view, GC-ed memory is useful for any data for which the developer 
does not know really its life span. So if some pass allocate data and 
does not know when the data is dead, it should be in GC-ed memory.

This is precisely the scenario for which my proposed 
ggc_collect_extra_marking is useful: there is some local data (on the 
call stack) which could point to some other data for which GC-ed 
allocation useful. Of course it is not worth using the GGC for only the 
local data. But this local data could point to other stuff. And we don't 
know when this other stuff should be freed. We leave that to the GC.

Of course, the proposed ggc_collect_extra_marking is only useful in 
those cases. But they can happen.

Again, my focus is only for the GGC collector explicitly called *inside* 
passes, and managing data whose lifespan is statically unknown.

Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
membre de l'APRIL "promouvoir et défendre le logiciel libre"
Rejoignez maitenant pplus de 3900 adhérents http://www.april.org

More information about the Gcc-patches mailing list