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 >>