• A limitation, which is shared by other points-to analysis, is that it's not clear how to more closely integrate efficient with other dataflow analyses/abstract interpreters. The information from the pointer analysis can greatly aid the other analysis and vice-versa (the use of types to refine the points-to sets is a limited example of this).
• The interesting thing to me (and the attractive thing to the authors) about this framework is the fact that the size of the representation adapts to the underlying information, and is therefore not necessarily in proportion to the overall fidelity. In other words, large subtrees of the decision graph can be collapsed into a single state without loss of precision, while other parts of the graph may remain fully expanded when there is a full set of decisions to be expressed there.
• It seems that once you think to try to use BDDs for pointer analysis, the rest of the work done in the paper is fairly straightforward. The lack of an on-the-fly call graph is a somewhat significant limitation; previous and subsequent work has shown that pointer analysis results are considerably more precise when the call
  graph is built on-the-fly (Whaley later shows how on-the-fly call graph construction can be integrated into a BDD analysis).
• It seems that similar BDD-based techniques could make a large difference for some sort of flow-sensitive points-to analysis. Here the space requirements are even more onerous, since you are trying to represent the points-to relation at every program point. Furthermore, the points-to relation for many program points will be very similar. It's still not clear how large a program one could analyze, but it would be interesting to see.
• I guess the main insight of the paper was "Hey, we could use BDDs for this!". Besides that, the only novel content I see are the empirically validated variable ordering and incremental evaluation heuristics.
• One weakness of the paper is that it does not provide any intuition as to why the ordering that it selected is advantageous for this problem. Also, the 'incrementalization' optimization is almost certainly a special case of a more general algorithm that has been reported elsewhere, and it would be interesting to see a tie to some of this optimization's other applications. If the incrementalization optimization is novel, then it should be treated more carefully in the paper.
• The BDD paper shows empirical results on how variable ordering can significantly affect the performance of the BDD points-to algorithm. While it is good that the authors found an ordering that improved performance, their explanation on why their best ordering works well is not satisfactory. Their explanations do not offer insights to the readers who would like to use BDD on other analyses. They made observations on what ordering makes the difference, but do not explain why the ordering is effective. In particular, it is not clear why the following are true:
  1. The relprod operation in BuDDy is sensitive to not only the size of the operands but also the variable ordering.
  2. Placing v1 before h1 allows better exploits of regularity and compact representation, as the points-to set gets large.
• The extension I would like to see is a more systematic treatment of the defition of locations. For some problems, such as virtual call resolution, location could be defined as 'dynamic type', which should make the analysis smaller and faster. In fact, for virtual calls, it may be possible to use an even coarser definition of location, because two different types often have the same code for method 'foo'. For other problems, as noted above, it may be necessary to have context sensitivity in varying amounts. In the factory method example, it may be enough for some purposes to refine the allocation site with a call string of length one. In the loop example, it may be possible to do something analogous, like breaking the location into two: "allocation on current iteration" and "all allocations from previous iterations." Generalizing a bit more, variables can be broken down different ways. As mentioned above, they can be distinguished by context. But we could also break them up further, by distinguishing globals by current call stack, using SSA on locals, and possibly even by considering temporal or dynamic call graph features such as "has function g() called and returned before now?" Of course, we can also partially collapse any of these levels. What I'm thinking is that the programmer probably had some clue about different usages of the variables, breaking down on lines of the kinds sketched above, and that an analysis using exactly that level of sensitivity in exactly the right places could efficiently produce very precise, concise results. I offer a (possibly stomach-turning) analogy: current points-to analysis is like dissecting an animal by cutting it on a grid pattern into 1-cm cubes. I want to cut it at the joints.
• The next step should be in finding a principle way to find a good ordering of the variables. This would benefit greatly to people that would like to use BDD to implement other analyses. It is likely that they would run into the same ordering problem as the authors did with points-to analysis.
• BDD is not likely to fit the demand driven analysis domain b/c it’s great only with set propagation algorithm. There may be other points-to analysis approach that can take advantage of BDD. CFL reachability can’t take advantage of it b/c CFL by itself doesn’t require much memory at all. However, if BDD can be used as the data structure to cache the points-to sets after the analysis.
• It would have been nice to have an algorithmic discussion of the BDD complexity in general and how this translates to the complexity of their algorithm. It makes it a bit harder to compare to, say the CFL implementation which stated their complexity as cubic I think.
• Interestingly, the BDD approach gains competitive time performance with only a fraction (15-25%) the memory consumption of a highly-optimized dedicated tool. But, even more interesting is the fact that space consumption growth is sub-linear, keeping the analysis within the feasible domain for huge problem sizes, whereas the dedicated analyzer would already "explode".
• There are a few possible next steps.
  - Make the analysis context-sensitive.
  - Make it demand-driven.
  The first improvement has already been made. It's not clear to me how the second one might work, but perhaps it's possible. Also, I think a really interesting paper would be one that really examines the structure of the alias analysis problem and describes the structural regularities that these BDDs are exploiting. That information would be extremely interesting. Perhaps further variable ordering optimizations could result from it.
• Although the call graph is currently constructed by a separate tool, it seems that the dynamic dispatch resolution can be done with BDDs (as hinted in the
  paper). This foreshadows a kind of iterative call graph construction that is integrated with the points-to analysis. The authors refer in passing to the
  difficulty of analysing the Java STK due to its enormous size. Perhaps, a good idea may be to pre-compute points-to summary information for the STK classes and reuse it with every benchmark. This would be similar to the way procedure summaries are computed for interprocedural analysis.
• Limitations of the paper are generally associated with its technical quality. Efficiency of the proposed technique is asserted only by means of experimental
  results. Asymptotical bounds for the involved computational costs are not provided. It might by possible to provide such bounds through a careful study of
  the implemented algorithm and the involved BDD operations. Similarly, due to the fixed number and type of fields and relations, it might by possible to derive
  a more robust, even theoretically provable, principle underlying the optimized variable ordering.
• BDD's are one kind of generic technique that people have been using lately for solving a variety of problems with out-of-the-box tools. SAT
  solvers are another one. One thing I've wondered about is applying these solvers to problems like ML-style type inference. While there are
  efficient algorithms for ML type inference, things are murkier for more semantically rich type systems that start to look like behavior
  specifications. Maybe we could build efficient solvers with these well-understood techniques.
• I find it interesting that different communities use BDDs, but each has a different name for it. For example, D. J. Bernstein refers to them as "crit bit trees", while they were originally published under the name PATRICIA by Morrisson in 1968. http://cr.yp.to/critbit.html
• One limitation is that the memory model is "logical" here, i.e. assuming pointers do not move beyond object boundaries. For languages like C, this is not enough. A real byte level memory model will be needed and whether BDD can still be used is unknown.
• One weakness seems to be the very high sensitivity of the running time to the ordering of the variables. It may be possible that there are interesting programs for which the heuristics listed won't work.
• On Section 4.4 in Reps: The existence of the "is-pointed-to" relation in the graph suggests that it could also be used to solve the "is-pointed-to" problem on demand, and the question of which variables are pointing to a given storage space may be just as important as which storage spaces a variable may be pointing to.