Are Your Incoming Aliases Really Necessary? Remembering the Cost of Object Ownership.
This talk will recap our paper from ICSE 2013 with an abstract available in a one minute video on YouTube: https://www.youtube.com/watch?v=3MkSMgqRhg0 . Having worked on Aliasing, Confinement, and Ownership and more recently on Aliasing, Capabilities, and Ownership a question arose: “What If We Actually Implement It?”. And so we did, to be able to measure and show everyone how costly it all really is. Random questions throughout the talk from the audience on the quality of Java corpora currently in existence, on the frequency of developer costs being taken into account in type checking research, and what it all has to do with power laws are welcome. The original text version of the abstract of the ICSE paper is reiterated for your convenience in the following paragraph.
Object ownership enforces encapsulation within object-oriented programs by forbidding incoming aliases into objects’ representations. Many common data structures, such as collections with iterators, require incoming aliases, so there has been much work on relaxing ownership’s encapsulation to permit multiple incoming aliases. This research asks the opposite question: Are your aliases really necessary? In this paper, we count the cost of programming with strong object encapsulation. We refactored the JDK 5.0 collection classes so that they did not use incoming aliases, following either the owner-as-dominator or the owner-as-accessor encapsulation discipline. We measured the performance time overhead the refactored collections impose on a set of microbenchmarks and on the DaCapo, SPECjbb and SPECjvm benchmark suites. While the microbenchmarks show that individual operations and iterations can be significantly slower on encapsulated collection (especially for owner-as-dominator), we found less than 3% slowdown for owner-as-accessor across the large scale benchmarks. As a result, we propose that well-known design patterns such as Iterator commonly used by software engineers around the world need to be adjusted to take ownership into account. As most design patterns are used as a building block in constructing larger pieces of software, a small adjustment to respect ownership will not have any impact on the productivity of programmers but will have a huge impact on the quality of the resulting code with respect to aliasing.
I am a Senior Lecturer in the School of Engineering and Computer Science at Victoria University of Wellington, New Zealand.
I am originally from Moscow, Russia with a background in Mathematics. I have completed my PhD in programming languages in 2006 and took up a job as a Lecturer in Software Engineering at Victoria University of Wellington. During my studies I took short breaks to work as a Visiting Researcher at Purdue University, and Software Engineer at two Wellington start-ups. I spent 2013 on sabbatical at Carnegie Mellon University in Pittsburgh, PA, USA.
Mon 19 JunDisplayed time zone: Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna change
11:00 - 12:30
|Spencer: Tracing as a Service|
Stephan Brandauer Uppsala University
|Are Your Incoming Aliases Really Necessary? Remembering the Cost of Object Ownership.|
Alex Potanin Victoria University of Wellington
|Reference Capabilities in Practice: Examining Real-World Pony Code|
Sylvan Clebsch Imperial College London