[cfe-dev] [analyzer] Zombie symbols.

[Craig, Ben via cfe-dev]

On 3/25/2016 9:18 AM, Artem Dergachev via cfe-dev wrote:
> > At which point is the symbol removed from the state? It that a
> > byproduct of the store?
>
> Well, yeah, i guess it's probably even "the primary product" - to 
> erase the original value while overwriting. And once the original 
> value is erased, it's no longer referenced.
>
> > > 1. Scan all symbols in the SymbolManager to find zombie symbols,
> > > deprecate the maybeDead() mechanism.
> > > 2. Wait until some kind of smart data map takes care of this extra 
> work.
>
> > Are you talking about a data structure that keeps track of the
> > data stored by the checkers. Presumably, that could be scanned
> > to find out which symbols are tracked by the checkers? This
> > direction looks the most appealing at this point.
>
> Seems so; why i'm also thinking of "1." is because i feel it'd make 
> removeDeadBindings sooo much easier to understand and sooo much more 
> intuitive - which it seems to need, as even an issue as simple as this 
> one had remained unnoticed. It seems that everybody was thinking that 
> "1." is already there. "The garbage collector was supposed to see 
> which symbols are referenced and remove those that aren't, how else 
> could it work?" In this case, we probably wouldn't even need a 
> worklist [which currently iterates only through the store, but also 
> needs to iterate through the GDM at the same time, as there may be 
> mutual dependencies between symbols here and there] during garbage 
> collection, just rely on later iterations to clean up sub-symbols step 
> by step. So i'd probably give it a try some day and try to explain it 
> in more details if something useful shows up.
>
> Though i've no idea about performance; the worklist would most likely 
> still have better performance.
The removeDeadBindings code path is currently one of the larger 
bottlenecks in the code.  Something like 20-25% of the time is spent 
there.  This is largely because there is mark-and-sweep algorithm 
performed here, and mark-and-sweep is great at causing lots of cache 
misses in the short term and invalidating the processor cache for later 
code.  I really want to spend some time here, but that code is pretty 
difficult to understand (as you noted), and other tasks have gotten in 
the way for now.
> And also, if we make a new API for the data map, the old API might 
> still want to be fixed somehow.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project