The first two variants of points-to-analysis (PTA) are “just” increasingly precise versions of PTA. The last one (on-the-fly) is both, more precise and more efficient because it only explores parts of the program “on demand” and continues only if the result is not found to be sufficiently precise yet.
To analyse Java we need a good understanding of the “anatomy” of the language. Seminar topics could be its type system, concurrency, etc. Basically everything that is necessary to fully understand the FindBugs bug specifications (which are often very brief and assume very detailed knowledge of the language specification).
Currently, there exists a Prolog-based implementation of
created in another lab. In this prototype, the call graph is created upfront based on “worst case” assumpitons (just the static type information. Then the PTA is performed on the worst-case call graph.
In our lab, a team of 3-4 people would work on improving it by
mutually use each other. This would probably integrate some “on-the-fly” ideas.
approach to include context-sensitivity.
In the seminar, this team would start by giving talks on
as introduced above.