singleton instances, unclear memory ownership

[dtzWill]

• Data-structures not created by not destroyed
  • unable to run same analysis on different modules (in sequence) due to persisting datastructures (like SymbolInfo).
• Singletons are expected to be initialized for current module/analysis
  • can't analyze modules in parallel.
• Unclear ownership/sharing patterns, especially regarding PAG and SymbolInfo.
• Non-static instances using singletons fail in unexpected ways if singletons already existed for another reason.
  • complicates use of analysis in a PassManager

The current code is remarkably close to being free of these singletons but requires some careful work to remove them while preserving the overall architecture. I tried locally but it was a bit of a mess O:).

Is this something you could look at?

[yuleisui]

Hi Will,

Thanks for pointing out.

1. Singleton
   Yes, SymbolInfo and PAG serves as the foundations for many other graph representations. Given the whole program bc files linked by Gold Plugin, SVF allows only one PAG instance instead of repeatedly building PAG (accidentally by the user) for interprocedural analysis .
2. Same analysis on different modules in sequence
   We assume SVF accepts only one modules at a time.
3. Analyze modules in parallel
   No, we can't analyze modules in parallel due to this design.

Yes, we will have a look at it but make sure one to one mapping from module to PAG. If a user creates multiple PAGs for a single module, the results carried from one analysis to another may be incomplete, of course adding unnecessary overhead.