[cfe-dev] [analyzer] Zombie symbols.
Craig, Ben via cfe-dev
cfe-dev at lists.llvm.org
Fri Mar 25 07:40:31 PDT 2016
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
> > 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
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
More information about the cfe-dev