1 Recency Types for Dynamically- Typed, Object-Based Languages Phillip Heidegger, Peter Thiemann University of Freiburg 06/24/2010

2 Create a static analysis of JavaScript for: ● Documentation ● Understanding programs ● Finding bugs Motivation

3 Features of JavaScript ● Object-based language (no classes, but prototypes) ● Functions are first class values ● Weak, dynamic typing ●... ● The combination of these features makes a static analysis a challenge

4 Approach ● We concentrate on a core calculus ● We decide to use recency abstraction ● We model this analysis as a type system

5 Core Calculus ● lambda calculus ● imperative objects ● read/write properties ● add properties ● delete properties ● prototypes

6 Recency Abstraction ● Gogul Balakrishnan and Thomas W. Reps. Recency- abstraction for heap-allocated storage. SAS ● S. H. Jensen, A. Møller, and P. Thiemann. Type analysis for JavaScript, SAS 2009 ➔ These papers are based on abstract interpretation ➔ Our work models recency abstraction in a type system

7 Example - Bank Account Typical Problem during object initialization: ● Initialize the customer of the bank account ● Initialize a account passing the corresponding owner ● setting the “account” property of the customer to its account

8 Bank Account concrete heap abstract heap 1 function Customer(n){ return { name: n }^L1; }; 2 function Account(o) { return { owner: o }^L2; }; 3 var c1 = Customer(“Lee”), a1 = Account(c1); 4 c1.account = a1; 5 var c2 = Customer(“Smith”), a2 = Account(c2); 6 c2.account = a2; aged objects most recent objects

9 Bank Account 1 function Customer(n){ return { name: n }^L1; }; 2 function Account(o) { return { owner: o }^L2; }; 3 var c1 = Customer(“Lee”), a1 = Account(c1); 4 c1.account = a1; 5 var c2 = Customer(“Smith”), a2 = Account(c2); 6 c2.account = a2; owner: name: “Lee” L1 L2 c1 a1 concrete heap abstract heap aged objects most recent objects

10 Bank Account 1 function Customer(n){ return { name: n }^L1; }; 2 function Account(o) { return { owner: o }^L2; }; 3 var c1 = Customer(“Lee”), a1 = Account(c1); 4 c1.account = a1; 5 var c2 = Customer(“Smith”), a2 = Account(c2); 6 c2.account = a2; owner: name: “Lee”, account: L1 L2 c1 a1 concrete heap abstract heap aged objects most recent objects

11 Bank Account 1 function Customer(n){ return { name: n }^L1; }; 2 function Account(o) { return { owner: o }^L2; }; 3 var c1 = Customer(“Lee”), a1 = Account(c1); 4 c1.account = a1; 5 var c2 = Customer(“Smith”), a2 = Account(c2); 6 c2.account = a2; owner: name: “Lee”, account: L1 L2 c1 a1 concrete heap abstract heap aged objects most recent objects owner: name: “Smith”name: String L2 c2 a2 L1

12 Bank Account 1 function Customer(n){ return { name: n }^L1; }; 2 function Account(o) { return { owner: o }^L2; }; 3 var c1 = Customer(“Lee”), a1 = Account(c1); 4 c1.account = a1; 5 var c2 = Customer(“Smith”), a2 = Account(c2); 6 c2.account = a2; owner: name: “Lee”, account: L1 L2 c1 a1 concrete heap abstract heap aged objects most recent objects owner: name: “Smith”, account: L2 c2 a2 L1

13 Bank Account 3 var c1 = Customer(“Lee”), a1 = Account(c1); 4 c1.account = a1; 5 var c2 = Customer(“Smith”), a2 = Account(c2); 6 c2.account = a2; 7 var c3 = Customer(“Hall”), a3 = Account(c3); 8 c3.account = a3; owner: name: “Lee”, account:name: String, account: L1 L2 concrete heap abstract heap aged objects most recent objects owner: name: “Smith”, account: owner: name: “Hall” L2 c3 a3 L1

14 Bank Account owner: name: “Lee”, account:name: String, account: L1 L2 concrete heap abstract heap aged objects most recent objects owner: name: “Smith”, account: owner: name: “Hall”, account: L2 c3 a3 L1 3 var c1 = Customer(“Lee”), a1 = Account(c1); 4 c1.account = a1; 5 var c2 = Customer(“Smith”), a2 = Account(c2); 6 c2.account = a2; 7 var c3 = Customer(“Hall”), a3 = Account(c3); 8 c3.account = a3;

15 Observation ● each most recent object has its own abstract description ➔ update of object → update of description strong update ● all aged objects share a description ➔ update of object → join of description relation n - 1 relation

16 Approach ● We concentrate on a core calculus ● We decide to use recency abstraction ● We model this analysis as a type system

17 Why a type system? ● type system models bidirectional flow of values ● modularity (principal type)

18 The Type System The type system has a flow sensitive and a flow insensitive part ● treat types for most recent objects flow sensitive ➔ “strong updates” in the flow sensitive part ● treat types for aged objects flow insensitive ➔ “weak updates” for old objects

19 Structure of Function Types most recent environment type of argument return type effect of function ● the effect together with the most recent heap environments is required for modularity

20 Invariant of the Type System ● ensure that we have a 1 to 1 relation between most recent objects and their types ➔ the effect helps maintain this invariant: ➔ collect abstract location for which a new object may be created during execution ➔ attach the effect to the function type ➔ frees most recent heap for all abstract locations that are part of the effect of the function

21 Javascripts' Prototypes ● JavaScript's mechanism for inheritance ● Prototypes are usually singleton objects ➔ They stay most recent ➔ We can allow strong updates during the full execution of the program ➔ Give flexibility to objects that are in the summary heap

22 Related Work ● Christopher Anderson, Paola Giannini, and Sophia Drossopoulou. Towards type inference for JavaScript. ECOOP 2005 ● We can type each program they can type ● We allow type changes (for most recent objects) ● We can deal with prototypes

23 Related Work ● Frederick Smith, David Walker, and J. Gregory Morrisett. Alias types. ESOP ● David Walker and Greg Morrisett. Alias types for recursive data structures. TIC 2000 Alias Types ● Type checking ● unroll/unpack operations Recency Types ● Type inference ● No movement from summary into most recent heap

24 Paper Contents ● Operational semantics of core calculus ● two heaps (most recent / old objects) ● Type soundness proof ● Type inference algorithm ● Prototype implementation

25 Conclusion ● Recency and flow sensitivity allows: ● strong updates during initialization ● weak updates after initialization ➔ Strong updates on prototypes ● Type soundness proof ● Prototype implementation ● Future Work ● implement modularity (remove closed world assumption) ● support full core calculus of “The Essence of JavaScript” Arjun Guha, Claudiu Saftoiu, Shriram Krishnamurthi. The Essence of JavaScript. ECOOP 2010 ● real world programs

26 Thank you for your attention ! Questions?