[cfe-dev] [analyzer] Zombie symbols.
Artem Dergachev via cfe-dev
cfe-dev at lists.llvm.org
Fri Mar 25 07:18:22 PDT 2016
> 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.
And also, if we make a new API for the data map, the old API might still
want to be fixed somehow.
More information about the cfe-dev