[RFC] two-phase marking in gt_cleare_cache

[Tom de Vries]

On 09/07/15 14:24, Michael Matz wrote:
> Hi,
>
> On Thu, 9 Jul 2015, Tom de Vries wrote:
>
>>>> Given this I think the call to gt_ggc_mx is superfluous because it
>>>> wouldn't work relyably for multi-step dependencies anyway.  Hence a
>>>> situation that works with that call in place, and breaking without
>>>> it is actually a bug waiting to be uncovered.
>>>
>>> Attached patch tries to get multi-step dependencies right, without
>>> using iteration-till-fixed-point.
>>
>> And for the record, attached patch implements a naive iterative
>> approach.
>
> What uses do multi-step dependencies have?  As in, I think this goes into
> the wrong direction, we lived without this since years, so why should this
> situation be handled at all?  It's about cache hash tables, so they
> shouldn't contain anything that is only pointed to at by entries in those
> tables.
>
> If anything we rather should check, that calling gt_ggc_mx on anything
> retained in the hash tables doesn't generate newly live objects.
>

Hi Michael,

I'm trying to get to a defined policy for what is allowed for caches. 
Either forbidding or allowing multi-step dependencies, I don't really mind.

Until now, we didn't have a good way of allowing them. I came up with a 
runtime efficient but not exhaustive variant, which I posted here: 
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00711.html.
As contrast and for the record, I posted the exhaustive but not runtime 
efficient variant here: 
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00730.html.

I managed to write a patch series that implements the forbidding of 
multi-step dependencies. I'll post this soon.

Thanks,
- Tom