CallGraph

Clone the instructions in methodNode into a new InsnList, mapping labels according to the labelMap.

For invocation instructions, set the callGraph.callsitePositions to the callsitePos.

Returns

• the new instruction list
• a map from old to new instructions
• a bit set containing local variable indices that are stored into

Store the position of every MethodInsnNode during code generation. This allows each callsite in the call graph to remember its source position, which is required for inliner warnings.

The call graph contains the callsites in the program being compiled.

Indexing the call graph by the containing MethodNode and the invocation MethodInsnNode allows finding callsites efficiently. For example, an inlining heuristic might want to know all callsites within a callee method.

Note that the call graph is not guaranteed to be complete: callsites may be missing. In particular, if a method is very large, all of its callsites might not be in the hash map. The reason is that adding a method to the call graph requires running an ASM analyzer, which can be too slow.

Note that call graph entries (Callsite instances) keep a reference to the invocation MethodInsnNode, which keeps all AbstractInsnNodes of the method reachable. Adding classes from the classpath to the call graph (in addition to classes being compiled) may prevent method instruction nodes from being GCd. The BCodeRepository has a fixed size cache for parsed ClassNodes - keeping all ClassNodes alive consumed too much memory. The call graph is less problematic because only methods being called are kept alive, not entire classes. But we should keep an eye on this.

Closure instantiations in the program being compiled.

Indexing closure instantiations by the containing MethodNode is beneficial for the closure optimizer: finding callsites to re-write requires running a producers-consumers analysis on the method. Here the closure instantiations are already grouped by method.