On Tue, Jul 14, 2015 at 12:45 PM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On Sun, Jul 12, 2015 at 5:53 PM, Tom de Vries <tom_devr...@mentor.com> wrote:
>> On 12/07/15 17:45, Tom de Vries wrote:
>>>
>>> Hi,
>>>
>>> this patch series implements the forbidding of multi-step garbage
>>> collection liveness dependencies between caches.
>>>
>>> The first four patches downgrade 3 caches to non-cache, since they
>>> introduce multi-step dependencies. This allows us to decouple:
>>> - establishing a policy for multi-step dependencies in caches, and
>>> - fixing issues that allow us to use these 3 as caches again.
>>>
>>> 1. Downgrade debug_args_for_decl to non-cache
>>> 2. Add struct tree_decl_map_hasher
>>> 3. Downgrade debug_expr_for_decl to non-cache
>>> 4. Downgrade value_expr_for_decl to non-cache
>>> 5. Don't mark live recursively in gt_cleare_cache
>>>
>>> Bootstrapped and reg-tested on x86_64, with ENABLE_CHECKING.
>>>
>>> I'll post the patches in response to this email.
>>
>>
>> This patch downgrade value_expr_for_decl to non-cache.
>>
>> OK for trunk?
>
> Similar to the debug_decl_map the idea of this hash is that
> it records on-the-side info for an entity.  If that entity is no
> longer needed then we should discard the reference so we
> can collect the entity.  Whether the on-the-side info is used
> in other means isn't relevant here.
>
> Note that they are also not really "caches" in that removing
> an entry for a key that is still live will cause information loss
> that cannot be restored.
>
> What's the bad side-effect of the "late" marking other than
> affecting this (or other) caches?
>
> What's your idea of restoring the "idea" of these maps under
> the constraint you try to add?

For example have those special caches have two marking phases.
The first phase marks all non-key edges originating from each entry.
The second phase is the same as what we have now - unmarked
entries get removed.

The first phase would go with regular marking, the second when
processing caches.

You'd delay collecting the memory the non-key edges point to
to the next GC run, but I think that's a fair trade-off.

Richard.

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

Reply via email to