Re: [RFC] two-phase marking in gt_cleare_cache

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, Jul 6, 2015 at 3:25 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Mon, Jul 6, 2015 at 10:57 AM, Tom de Vries <Tom_deVries@mentor.com> wrote:
>> Hi,
>>
>> Using attached untested patch, I managed to minimize a test-case failure for
>> PR 66714.
>>
>> The patch introduces two-phase marking in gt_cleare_cache:
>> - first phase, it loops over all the hash table entries and removes
>>   those which are dead
>> - second phase, it runs over all the live hash table entries and marks
>>   live items that are reachable from those live entries
>>
>> By doing so, we make the behaviour of gt_cleare_cache independent of the
>> order in which the entries are visited, turning:
>> - hard-to-trigger bugs which trigger for one visiting order but not for
>>   another, into
>> - more easily triggered bugs which trigger for any visiting order.
>>
>> Any comments?
>
> I think it is only half-way correct in your proposed change.  You only
> fix the issue for hashes of the same kind.  To truly fix the issue you'd
> have to change generated code for gt_clear_caches () and provide
> a clearing-only implementation (or pass a operation mode bool to
> the core worker in hash-table.h).

Hmm, and don't we rather want to first mark and _then_ clear?  Because
if entry B in the hash is live and would keep A live then A _is_ kept in the
end but you'll remove it from the hash, possibly no longer using a still
live copy.

Richard.

> Thanks,
> Richard.
>
>> Thanks,
>> - Tom