Practical Static Analysis of JavaScript Applications in the Presence of Libraries and Frameworks

1. Practical Static Analysis of JavaScript Applications in the Presence of Libraries and Frameworks Magnus Madsen Benjamin Livshits Michael Fanning

2. Outline

3. Motivation Windows 8: • JavaScript is an officially supported language • .NET library bindings exposed to JavaScript Q: How can we use static analysis to improve the development experience?

4. The Challenge Modern JavaScript applications are often built using large and complex libraries: • Browser API, Win8 API, NodeJS, PhoneGap, ... • Problems: Reflection? native code? sheer size? • But: We really only care about the application! A pragmatic choice: We ignore the libraries (thus sacrificing soundness) to focus on the applications themselves

5. Practical Applications (which do not require soundness) • auto-complete • call graph discovery • capability usage • API usage

6. Practical Applications (which do not require soundness) • auto-complete • call graph discovery • capability usage • API usage

7. Practical Applications (which do not require soundness) • auto-complete • call graph discovery • capability usage • API usage <Capabilities> <Capability name="internetClient"/> <Capability name="picturesLibrary"/> <DeviceCapability name="location"/> <DeviceCapability name="microphone"/> <DeviceCapability name="webcam"/> </Capabilities>

8. Practical Applications (which do not require soundness) • auto-complete • call graph discovery • capability usage • API usage • Windows.Devices.Sensors • Windows.Devices.Sms • Windows.Graphics.Display • Windows.Graphics.Printing • Windows.Media.Capture • Windows.Networking.Sockets • Windows.Storage.Search

9. Win8 & Web Applications Windows 8 App Web App Builtin Builtin DOM DOM WinJS WinJS Win8 Win8 Builtin Builtin DOM DOM jQuery jQuery … … 3000 functions

10. Introducing Use Analysis elm flows into reset elm flows into playVideo elm must have: muted and play elm must have: pause Conclusion: elm is a HTMLVideoElement

11. Use Analysis: Determines what an object is based on how it is used

12. Outline

13. Heap Partitioning Library Heap Application Heap "Symbolic Heap"

14. Symbolic Objects and Unification • Introduce symbolic objects where flow is dead (i.e. missing) due to libraries. • Collect information about where the symbolic objects flow and how they are used. • Unify symbolic objects with "compatible" application or library objects.

15. Example: Iteration 1 We discover that c is a dead return

16. Example: Iteration 2 We introduce a symbolic return object

17. Example: Iteration 3 We unify the symbolic object with the HTMLCanvasElement

18. Missing Flow Where can dataflow be missing when ignoring the library code?: • Dead Returns • Dead Arguments • Dead Loads • Dead Prototypes • Dead Array Accesses

19. Unification Strategies Unification strategies based on property names: • : a single shared property name • :all shared property names • : all shared property names, but prioritize prototype objects x x x z y x y Application Symbolic Application

20. Outline

21. Benchmarks 25 Windows 8 Apps: Average ~1,500 lines of code Approx. 30,000 lines of stubs

22. Call Graph Resolution Pointer Analysis Pointer Analysis + Use Analysis A call site is resolved if it has a non-empty set of call targets

23. Auto-complete • We compared our technique to the auto-complete in four popular IDEs: • Eclipse for JavaScript developers • IntelliJ IDEA 11 • Visual Studio 2010 • Visual Studio 2012 • In all cases, where libraries were involved, our technique was an improvement

24. Auto-complete: Case study  35   0 26 1    9  0 7 k      50 0 7 7    50 0 1 k     0 7 k 250 

25. Soundness & Completeness Use Analysis is inheritenly unsound: • library code is not analyzed • library code could have arbitrary side-effects An example of unsoundness An example of incompleteness: ... results of manual (human) inspection of 200 call sites

26. Findings • Auto-completion is improved compared to four popular IDEs • Use analysis improves call graph resolution • In practice unsoundness is limited • Reasonable analysis time median analysis time of 10s for apps of avg 1500 loc

27. Summary Pointer analysis + Use analysis: • A technique to statically reason about JavaScript applications which rely on large and complex libraries without analyzing the libraries themselves Practical applications: • auto-complete • API usage • capability discovery • call graph construction Thank You

29. Architecture JavaScript Application Introduce New Facts App Facts Pointer Analysis Use Analysis Analysis Rules

33. Datalog Formulation We define the following domains: – variables – heap-allocated objects – property names – call sites – integers (e.g. argument offsets) Based on Gatekeeper (Livshits et al. 2009)

34. Pointer Analysis PointsTo(v, h) :- NewObj(v, h, _). PointsTo(v1, h) :- Assign(v1, v2), PointsTo(v2, h). PointsTo(v2, h2) :- Load(v2, v1, p), PointsTo(v1, h1), HeapPtsTo(h1, p, h2). HeapPtsTo(h1, p, h2) :- Store(v1, p, v2), PointsTo(v1, h1), PointsTo(h2, h2). HeapPtsTo(h1, p, h3) :- Prototype(h1, h2), HeapPtsTo(h2, p, h3). CallGraph(c, f) :- ActualArg(c, 0, v), PointsTo(v, f). Assign(v1, v2) :- CallGraph(c, f), FormalArg(f, i, v1), ActualArg(c, i, v2), z > 0. Assign(v1, v2) :- CallGraph(c, f), FormalRet(f, v1), ActualRet(c, v2).

35. Example: Dead Returns DeadRet(c, v) :- CallGraph(c, f), ActualRet(c, v), !ResolvedVar(v), !AppAlloc(f). DeadArg(f, i) :- FormalArg(f, i, v), !ResolvedVar(v), AppAlloc(f). ...