J. Aldrich, V. Kostadinov, and C. Chambers. Alias Annotations for Program Understanding. In Object-Oriented Programming Systems, Languages, and Applications, November 2002.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....within a single subsystem, or a single result for each method. Our implementation currently produces a separate result for each distinct instantiation of token variable and subsystem values. 6. 4 Ownership Types Ownership type systems are designed to enforce object encapsulation properties [10, 7, 6, 9, 2]. In this capacity, they can be used to ensure that objects from one instance of an abstraction are not used to inappropriately communicate with With the possible exception of timing channels. 25 other instances of the same abstraction [5, 2] For example, one might use ownership types in a ....

....to enforce object encapsulation properties [10, 7, 6, 9, 2] In this capacity, they can be used to ensure that objects from one instance of an abstraction are not used to inappropriately communicate with With the possible exception of timing channels. 25 other instances of the same abstraction [5, 2]. For example, one might use ownership types in a multithreaded web server to ensure that the sockets associated with one server thread do not escape to be used by another server thread. Our system focuses on extracting communication patterns. Encapsulation violations in our system therefore show ....

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. Seattle, WA, Nov. 2002.

....a subobject by only considering methods in the object. This has been used in preventing data races and deadlocks [2] Various extensions have been proposed to allow restricted forms of access to objects without going through the owner[2, 7, 8] AliasJava uses a more flexible ownership type system[1]. While it is still not possible to change the ownership of an object, an owner can grant permission to access an object to another object, and aliases can be temporarily created to owned objects. More recent work has enabled the expression of parameterized containers and their iterators while ....

....scalability of this powerful technique has not been demonstrated. Automatic Inference. Our ownership inference is fully automatic and quite powerful. Automatic interprocedural annotation inferencing is also used in other software understanding tools in cluding Lackwit[23] Ajax[22] and AliasJava[1]. While all these tools support polymorphism, or context sensitivity, our algorithm is also flow sensitive unlike the first two of these. Moreover, we do not know of any other inference algorithms that allow choice in ownership transfer in assignment statements and method invocations. This idea is ....

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Proceedings of OOPSLA 2002.

.... for preventing data races [14] and deadlocks [10] for supporting modular software upgrades in persistent object stores [13] for modular specification of e#ects clauses in the presence of subtyping [11, 14] so they can be used as an alternative to data groups [36] and for program understanding [3]. We are currently unifying the type system presented in this paper with the above type systems [9] The unified ownership type system requires little programming overhead, its typechecking is fast and scalable, and it provides several benefits. The unified ownership type system thus o#ers a ....

....with shared regions, or real time programs with real time threads (although it should be possible to extend them to do so) Conversely, it should also be possible to apply these techniques to our system. In fact, existing systems already combine ownershipbased type systems and unique pointers [20, 14, 3]. RegJava [16] has a region type system for object oriented programs that supports subtyping and method overriding. Cyclone [34] is a dialect of C with a region type system. Our work improves on these two systems by combining the benefits of ownership types and region types in a unified ....

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

....is not accessible from anywhere else. Boyapati et al. 5] use a form of ownership as basis for a locking discipline: if a thread holds a lock on a certain object, it need not lock objects owned by that object. Strong forms of ownership have been proposed for various kinds of modular reasoning [14, 15, 10, 7, 23, 20, 1]. A typical ownership invariant is that an owned object is not accessible except via the object that owns it. Ownership is ubiquitous, as it is a natural embodiment of aggregation and the encapsulation of representations. Achieving such encapsulation is a key design objective, as it supports local ....

.... 4 Another point of concern is that downcasts are omitted from [6] and it appears that treating them requires runtime support; downcasts and subclassing pose nontrivial challenges for ownership systems and representation independence, which are addressed in our work and in some others (e.g. [8, 1]) by purely static means. Throughout the paper we omit both preconditions and error checking code. void transferTo(Fifo o) ListNode n : front; if (front= rear) front : null; rear : null; else front : front.getNxt0; n.setNxt(null) o.pushR(n) void transferFrom(Fifo o) ....

Jonathan Aldrich, Valentin Kostadinov, and Craig Chambers. Alias annotations for program understanding. In A CM Symposium on Object Oriented Programming: Systems, Languages, and Applications (00PSLA). ACM Press, 2002.

.... that use region based memory management [7] for supporting modular software upgrades in persistent object stores [5] for modular speci cation of e ects clauses in the presence of subtyping [4, 6, 10] so they can be used as an alternative to data groups [14] and for program understanding [2]. In ownership type systems, programmers parameterize classes and methods by owners. This enables the writing of generic code that can be used in many di erent contexts. The parameterization is somewhat similar to the proposals for parametric types for Java [1, 8, 16, 18] Ownership type systems ....

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

....result for each combination of token variable and subsystem values, a result that separates subsystems but combines information within a single subsystem, or a single result for each method. 6. 3 Ownership Types 10 Ownership type systems are designed to enforce object encapsulation properties [9, 6, 5, 8, 2]. In this capacity, they can be used to ensure that objects from one instance of an abstraction are not used to inappropriately communicate with other instances of the same abstraction [4, 2] For example, one might use ownership types in a multithreaded web server to ensure that the sockets ....

.... Types 10 Ownership type systems are designed to enforce object encapsulation properties [9, 6, 5, 8, 2] In this capacity, they can be used to ensure that objects from one instance of an abstraction are not used to inappropriately communicate with other instances of the same abstraction [4, 2]. For example, one might use ownership types in a multithreaded web server to ensure that the sockets associated with one server thread do not escape to be used by another server thread. Our system focuses on extracting communication patterns. Encapsulation violations in our system therefore show ....

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming Systems, Languages and Applications, Seattle, WA, Nov. 2002.

....approaches to managing aliasing in object oriented programming exist. On one hand sits unique or alias free references. These are based on a very simple idea: any variable or field annotated with the keyword unique contains the only reference to the object it holds, otherwise it contains null [26, 31, 9, 11, 8, 1]. Apart from helping reason about programs, unique references safely enable, for example, idioms essential in concurrent programming such as the transfer of ownership pattern [28] and help enforce software protocols [16] In all cases, the same notion of uniqueness applies. Unfortunately, all ....

....a program. The second approach to managing aliasing employs alias encapsulation, as exemplified by ownership types [15] Simply put, these impose a form of object level privacy by preventing objects (rather than just fields) from being accessed outside of their enclosing encapsulation boundaries [15, 32, 13, 8, 6, 14, 1]. Ownership types have been employed for reasoning about programs [14, 32] for alias management [15, 33] in program understanding [1] to eliminate data races [8] and deadlocks [6] from concurrent programs, and to enable safe lazy updates in object oriented databases [7] Existing attempts to ....

[Article contains additional citation context not shown here]

Jonathan Aldrich, Valentin Kostadinov, and Craig Chambers. Alias annotations for program understanding. In OOPSLA, November 2002.

....uniqueness elds and variables are destructively read, meaning that they are nulli ed once their contents are read. Usually a borrowing mechanism is available to increase the usability of uniqueness by allowing the unique reference to be temporarily passed to methods without being consumed [21, 27, 9, 10, 7, 1]. In all cases, the same notion of uniqueness remains. In this paper we argue that existing uniqueness proposals are broken, because they su er from at least one of the two problems we identify here. The abstraction problem occurs when changes to the implementation of an object with regard to ....

....internally. The treatment of this is re ected in the interface to a class. For example, Minsky [27] divides classes into two worlds, those which may assign this internally and those which do not. Only instances of the latter may be uniquely referenced. Hogg [21] Boyland [9] and Aldrich et.al. [1] annotate a class interface to indicate which methods consume this. Calling such a method requires a destructive read of the target object. Assume now that we have a eld referring to some object of class BlackBox, such as unique BlackBox bb. When we change the implementation of the BlackBox ....

[Article contains additional citation context not shown here]

Jonathan Aldrich, Valentin Kostadinov, and Craig Chambers. Alias annotations for program understanding. In OOPSLA, November 2002.

....clauses that prevent a program from following such pointers. The above systems e ectively enforce encapsulation for object elds. However, to support constructs like iterators, they allow method local variables to violate encapsulation. Therefore they do not support local reasoning. AliasJava [2] uses ownership types to aid program understanding. Like other ownership type systems, AliasJava allows programmers to use ownership information to reason about aliasing. AliasJava is also more exible than other ownership type systems. However, unlike other ownership type systems, AliasJava does ....

....to reason about aliasing. AliasJava is also more exible than other ownership type systems. However, unlike other ownership type systems, AliasJava does not enforce any encapsulation properties. This is illustrated with an example in [11] Ownership types have been extended to inner classes in [19, 2]. However, these systems do not enforce the property stated in Section 3.5, and do not support local reasoning. Ownership types have also been used to enforce other properties. Parameterized Race Free Java (PRFJ) 14] uses an ownership based type system to prevent data races in multithreaded ....

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

.... for preventing data races [14] and deadlocks [10] for supporting modular software upgrades in persistent object stores [13] for modular speci cation of e ects clauses in the presence of subtyping [11, 14] so they can be used as an alternative to data groups [36] and for program understanding [3]. We are currently unifying the type system presented in this paper with the above type systems [9] The uni ed ownership type system requires little programming overhead, its typechecking is fast and scalable, and it provides several bene ts. The uni ed ownership type system thus o ers a ....

....with shared regions, or real time programs with real time threads (although it should be possible to extend them to do so) Conversely, it should also be possible to apply these techniques to our system. In fact, existing systems already combine ownershipbased type systems and unique pointers [20, 14, 3]. RegJava [16] has a region type system for object oriented programs that supports subtyping and method overriding. Cyclone [34] is a dialect of C with a region type system. Our work improves on these two systems by combining the bene ts of ownership types and region types in a uni ed ....

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

....of a. Object encapsulation enables local reasoning about program correctness. Ownership types have also been used for statically preventing data races [9] and deadlocks [7] in Java programs, for supporting safe lazy upgrades in objectoriented databases [8] and for program understanding [3]. Our type system is based on the type system in [8] Ownership Relation Objects are allocated in regions. Every object in our system has an owner. An object can be owned by another object, or by a region. We write o1 if o1 directly or transitively owns o2 or if o1 is the same as o2 . The ....

....subtyping, multithreaded programs with shared regions, or real time programs with real time threads. Moreover, we can augment our system with linear types and other techniques used in the above systems. In fact, other systems have already combined ownership based type systems and unique pointers [12, 9, 3]. RegJava [11] describes a region type system for objectoriented programs that handles subtyping and method overriding. We improve on this by combining the benefits of ownership types and region types in a unified framework. Cyclone [28] is a dialect of C with a region type system. An extension ....

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

....ownership. A formal description of our type system is given in the appendix. The appendix also discusses how we can use type Ownership types have also been used for statically enforcing the absence of data races and deadlocks in multithreaded programs [10, 9] and to aid program understanding [2]. O1. The owner of an object does not change over time. O2. The ownership relation forms a tree rooted at world. Figure 1: Ownership Properties o5 o6 o7 o2 o4 o1 o3 world Figure 2: An Ownership Relation inference to make the ownership declarations less onerous to write, and discusses ....

....but the two can be used in conjunction to provide more expressive type systems. PRFJ [10] is the rst system to combine ownership types with unique pointers. This lets programmers express programming idioms that neither ownership types nor unique pointers alone can express. SCJ [9] and AliasJava [2] also combine ownership types with unique pointers. The type system we presented in this paper can be combined with unique pointers in an analogous way. Our ownership type system is somewhat similar to the type systems in Capability Calculus [18] Alias Types [48] and Cyclone [28] for doing ....

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In and Applications (OOPSLA), November 2002.

....races and deadlocks. We have recently developed an ownership type system [6] that statically enforces object encapsulation, while supporting subtyping and constructs like iterators. Other ownership type systems either do not enforce object encapsulation (they enforce weaker restrictions instead) [12, 7, 2], or they are not expressive (they do not support subtyping and constructs like iterators) 14, 13] We present a detailed discussion of ownership types in Section 7. We also describe how the type system in this paper can be combined with the type system in [6] to statically enforce object ....

....its subobjects. We have recently developed an ownership type system [6] that statically enforces object encapsulation, while supporting subtyping and constructs like iterators. Other ownership type systems either do not enforce object encapsulation (they enforce weaker restrictions instead) [12, 7, 2], or they are not expressive (they do not support subtyping and constructs like iterators) 14, 13] This section presents a detailed discussion of ownership types. This section also describeshowthetypesysteminthispapercanbecombined with the type system in [6] to statically enforce object ....

[Article contains additional citation context not shown here]

J.Aldrich,V.Kostadinov,andC.Chambers.Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

....ownership. A formal description of our type system is given in the appendix. The appendix also discusses how we can use type Ownership types have also been used for statically enforcing the absence of data races and deadlocks in multithreaded programs [10, 9] and to aid program understanding [2]. O1. The owner of an object does not change over time. O2. The ownership relation forms a tree rooted at world. Figure 1: Ownership Properties o5 o6 o7 o2 o4 o1 o3 world Figure 2: An Ownership Relation inference to make the ownership declarations less onerous to write, and discusses ....

....but the two can be used in conjunction to provide more expressive type systems. PRFJ [10] is the first system to combine ownership types with unique pointers. This lets programmers express programming idioms that neither ownership types nor unique pointers alone can express. SCJ [9] and AliasJava [2] also combine ownership types with unique pointers. The type system we presented in this paper can be combined with unique pointers in an analogous way. Our ownership type system is somewhat similar to the type systems in Capability Calculus [18] Alias Types [48] and Cyclone [28] for doing ....

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In and Applications (OOPSLA), November 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias Annotations for Program Understanding. In Object-Oriented Programming Systems, Languages, and Applications, November 2002.

No context found.

Jonathan Aldrich, Valentin Kostadinov, and Craig Chambers. Alias Annotations for Program Understanding. Proc. Object Oriented Programming Systems, Languages and Applications, Seattle, Washington, November 2002.

No context found.

Jonathan Aldrich, Valentin Kostadinov, and Craig Chambers. Alias Annotations for Program Understanding. Proc. Object-Oriented Programming Systems, Languages and Applications, Seattle, Washington, November 2002.

No context found.

J. Aldrich, V. Kostandinov, C. Chambers. Alias Annotations for Program Understanding. Proc. Object-Oriented Programming, Systems, Languages, and Applications, November 2002.

No context found.

Jonathan Aldrich, Valentin Kostadinov, and Craig Chambers. Alias Annotations for Program Understanding. University of Washington technical report UW-CSE-02-11-01, November 2002.

....rules representing casts that fail and null pointer dereferences. A set of congruence rules (such as if e e then e.f e .f) allows reduction to proceed in the order of evaluation defined by Java. We omit the congruence and error rules here, but they can be found in a companion technical report [AKC02]. S , C S ) C S[ S S = unique new domain (R NEW) S ) v A ) f A( S A ] A D A T f T C ) v ( C ] S[ R fields = owned unique lent b (R READ) S ) v ) f (A( S ) v ] v ( C S[ S C T f T C ) v ( C ] S[ ....

....and progress. Type soundness implies that the language s type system is well behaved. In a type safe language like Java, well typed programs won t halt with errors other than failed casts and null pointer exceptions. We state the theorems here, leaving the proofs to a companion technical report [AKC02]. Theorem [Subject Reduction] If T e : l S G , S , S G and S , e e S l , then T : T S S , such that T e S G : l and S , S G l . Subject reduction is proved by induction on the derivation of S , e e S l , with a case analysis on the last reduction rule used. A ....

[Article contains additional citation context not shown here]

Jonathan Aldrich, Valentin Kostadinov, and Craig Chambers. Alias Annotations for Program Understanding. University of Washington technical report UW-CSE-02-11-01, November, 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In OOPSLA, pages 311--330, 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In OOPSLA, 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Conference on Object-Oriented Programming Systems, Languages, and Applications, pages 311--330, 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Conference on Object-Oriented Programming Systems, Languages, and Applications, pages 311--330, 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Proceedings of the 17th ACM Conference on Object-Oriented pages 311--330, Seattle, Washington, November 2002.

No context found.

Jonathan Aldrich, Valentin Kostadinov, and Craig Chambers. Alias annotations for program understanding. In Proceedings of the 17th ACM Conference on Object-oriented Programming, Systems, Languages, and Applications, pages 311--330, Seattle, Washington, November 2002.

No context found.

Jonathan Aldrich, Valentin Kostadinov, and Craig Chambers. Alias annotations for program understanding. In OOPSLA, November 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Proceedings of Object-Oriented Programming Systems, Languages, and Applications, 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In ACM Conference on Object-Oriented Programming Languages, Applications, Languages, and Systems (OOPSLA), November 2002.

No context found.

Jonathan Aldrich, Valentin Kostadinov, and Craig Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

No context found.

Jonathan Aldrich, Valentin Kostadinov, and Craig Chambers. Alias annotations for program understanding. In Proceedings of the 17th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, pages 311--330, Seattle, Washington, USA, November 2002.

No context found.

Jonathan Aldrich, Valentin Kostadinov, and Craig Chambers. Alias annotations for program understanding. In ACM Symposium on Object Oriented Programming: Systems, Languages, and Applications (OOPSLA). ACM Press, 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

No context found.

Aldrich, J., Kostadinov, V., Chambers, C.: Alias annotations for program understanding. In: OOPSLA'02 Conference Proceedings---Object-Oriented Programming Systems, Languages and Applications, New York, ACM Press (2002) 311--330

No context found.

Jonathan Aldrich, Valentin Kostadinov, and Craig Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

No context found.

Jonathan Aldrich, Valentin Kostadinov, and Craig Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002. Chandrasekhar Boyapati et al.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming Systems, Languages, and Applications (OOPSLA 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In OOPSLA Proceedings, November 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding, 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding, 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), November 2002.

No context found.

J. Aldrich, V. Kostadinov. and C. Chambers. Alias annotations for program understanding. In ACM SIGPLAN conference on Object-Oriented Pogramming, Systems, Languages and Applications, pages 311 330. ACM Press, 2002.

No context found.

J. Aldrich, V. Kostadinov, and C. Chambers. Alias annotations for program understanding. In ACM Symposium on Object Oriented Programming: Systems, Languages, and Applications (OOPSLA), Nov. 2002.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC