We have applied BEAN to refine two state-of-the-art object-sensitive pointer analyses for Java.BEAN improves their precision for two representative clients on a set of nine Java programs in DaCapo at small time increases. 2 Motivation When analysing Java programs,there are two types of context,a method contert for local variables and a heap contert for object fields.In k-obj,a k-object- sensitive analysis [24,29],a method context is a sequence of k allocation sites and a heap context is typically a sequence of k-1 allocation sites.Given an allocation site at label e.e is also referred to as an abstract object for the site. Currently,k-obj,where k=2,represents a 2-object-sensitive analysis with a 1-context-sensitive heap (with respect to allocation sites),denoted 2obj+h[14], which usually achieves the best tradeoff between precision and scalability and has thus been widely adopted in pointer analysis for Java [8,21,29].In 2obj+h, a heap context for an abstract object e is a receiver object of the method that made the allocation of e(known as an allocator object).A method context for a method call is a receiver object of the method plus its allocator object. Below we examine the presence of redundant context elements in 2obj+h, with two examples,one for method contexts and one for heap contexts.This serves to motivate the BEAN approach proposed for avoiding such redundancy. 2.1 Redundant Elements in Method Contexts We use an example in Fig.1 to illustrate how 2obj+h analyses it imprecisely due to its use of a redundant context element in method contexts and how BEAN avoids the imprecision by avoiding this redundancy.We consider a may-alias client that queries for the alias relation between variables v1 and v2. In Fig.1(a),we identify the six allocation sites by their labels given in their end-of-line comments (in green),i.e.,A/1,A/2,0/1,0/2,B/1,and C/1. In Fig.1(b),we give the context-sensitive call graph computed by 2obj+h, where each method is analysed separately for each different calling context,de- noted by [...(in red).C.identify()has two concrete calling contexts but analysed only once under [B/1,C/1].We can see that B/1 is redundant (rela- tive to C/1)since adding B/1 to C/1 fails to separate the two concrete calling contexts.As a result,variables vi and v2 are made to point to both 0/1 and 0/2 at the same time,causing may-alias to report a spurious alias.During any program execution,v1 and v2 can only point to 0/1 and 0/2,respectively. In Fig.1(c),we give the context-sensitive call graph computed by BEAN, where C.identify()is now analysed separately under two different contexts, [A/1,C/1]and [A/2,C/1].Due to the improved precision,v1 (v2)now points to 0/1(0/2)only,causing may-alias to conclude that both are no longer aliases.– We have applied Bean to refine two state-of-the-art object-sensitive pointer analyses for Java. Bean improves their precision for two representative clients on a set of nine Java programs in DaCapo at small time increases. 2 Motivation When analysing Java programs, there are two types of context, a method context for local variables and a heap context for object fields. In k-obj, a k-object￾sensitive analysis [24, 29], a method context is a sequence of k allocation sites and a heap context is typically a sequence of k − 1 allocation sites. Given an allocation site at label `, ` is also referred to as an abstract object for the site. Currently, k-obj, where k = 2, represents a 2-object-sensitive analysis with a 1-context-sensitive heap (with respect to allocation sites), denoted 2obj+h [14], which usually achieves the best tradeoff between precision and scalability and has thus been widely adopted in pointer analysis for Java [8, 21, 29]. In 2obj+h, a heap context for an abstract object ` is a receiver object of the method that made the allocation of ` (known as an allocator object). A method context for a method call is a receiver object of the method plus its allocator object. Below we examine the presence of redundant context elements in 2obj+h, with two examples, one for method contexts and one for heap contexts. This serves to motivate the Bean approach proposed for avoiding such redundancy. 2.1 Redundant Elements in Method Contexts We use an example in Fig. 1 to illustrate how 2obj+h analyses it imprecisely due to its use of a redundant context element in method contexts and how Bean avoids the imprecision by avoiding this redundancy. We consider a may-alias client that queries for the alias relation between variables v1 and v2. In Fig. 1(a), we identify the six allocation sites by their labels given in their end-of-line comments (in green), i.e., A/1, A/2, O/1, O/2, B/1, and C/1. In Fig. 1(b), we give the context-sensitive call graph computed by 2obj+h, where each method is analysed separately for each different calling context, de￾noted by [...] (in red). C.identify() has two concrete calling contexts but analysed only once under [B/1,C/1]. We can see that B/1 is redundant (rela￾tive to C/1) since adding B/1 to [C/1] fails to separate the two concrete calling contexts. As a result, variables v1 and v2 are made to point to both O/1 and O/2 at the same time, causing may-alias to report a spurious alias. During any program execution, v1 and v2 can only point to O/1 and O/2, respectively. In Fig. 1(c), we give the context-sensitive call graph computed by Bean, where C.identify() is now analysed separately under two different contexts, [A/1, C/1] and [A/2, C/1]. Due to the improved precision, v1 (v2) now points to O/1 (O/2) only, causing may-alias to conclude that both are no longer aliases