Prof. Dr. Eric Bodden

I just read again through Identify the Champion by Oscar Nierstrasz. I have read it before but I just got a paper rejected so I thought I read it again 😉 The paper describes a pattern language for organizing a program committee meeting. What’s really valuable about the document is the fact that this pattern language has become something like the de facto standard in the field of Computer Science. As far as I can tell, all important conferences I submit to (OOPSLA, ECOOP, POPL, PLDI, …) use it for their review process now. You might like that or not. The point is that you have to cope with it and hence you should make sure to know how it works. The advise is already in the paper: Identify the champion! In the paper this is addressed to the program chair. It’s his task to identify persons who will be likely to “champion” a paper, i.e. stand up for it and fight for it to be accepted. In my opinion however, the challenge equally holds for people who submit to the conference. The unfortunate fact of “Identify the champion” is that your paper is not going to make it if there is nobody championing it. Hence, you as an author have to identify your champion as well! If you know people in the program committee and if you know that there is at least somebody of them who cares, write the paper for that person! In my opinion that makes it more likely to get your paper accepted. (I will tell you if it works after the notification deadline 😉 .)

Quick note: The OOPSLA 2007 Keynotes are now available as Podcasts!

Youtube has this video on the OOPSLA 2007 Panel “There is no silver bullet”. I thought, the panel was a lot of fun. The werewolf was a really cool idea (I finally got the silver bullet analogy), although it really shocked me at first. I was sitting on the floor in the back and just heard somebody shouting and screaming like hell. I already thought somebody was having a heart attack or something 😉 That’s what I like about OOPSLA – always something’s unexpected happens.

Authors: Eric Bodden, Patrick Lam and Laurie Hendren
Date: September 2007
Abstract
Pointer analyses enable many subsequent program analyses and transformations, since they enable compilers to statically disambiguate references to the heap. Extra precision enables pointer analysis clients to draw stronger conclusions about programs. Flow-sensitive pointer analyses are typically quite precise. Unfortunately, flow-sensitive pointer analyses are also often too expensive to run on whole programs. This paper therefore describes a technique which sharpens results from a whole-program flow-insensitive points-to analysis using two flow-sensitive intraprocedural analyses: a must-not-alias analysis and a must-alias analysis. The main technical idea is the notion of instance keys, which enable client analyses to disambiguate object references. We distinguish two kinds of keys: weak and strong. Strong instance keys guarantee that different keys represent different runtime objects, allowing instance keys to almost transparently substitute for runtime objects in static analyses. Weak instance keys may represent multiple runtime objects, but still enable disambiguation of compile-time values. We assign instance keys based on the results of our analyses. We found that the use of instance keys greatly simplified the design and implementation of subsequent analysis phases.

available here for download

It’s done. OOPSLA is over. I have to say, first I was skeptical about this year’s OOPSLA edition because there were so many tracks going on at the same time. However, one has to admit that in general there was a lot of interesting and funky stuff going on (and the research track was not always the most interesting one). So maybe it’s a good thing to have that variety after all. It’s hard to say, but anyway I had a good week with lots of fruitful discussions. As I understand, some videos of the most important keynotes and other stuff will be available on the OOPSLA or R.P. Gabriel’s website shortly.

Michael Bond presented an interesting approach to tracking the origin of unusable values such as null today at OOPSLA. His team uses a piggybacking approach, which makes this task very efficient. Instead of storing null when null is assigned, they store some special data structure encoding the location at which this assignment occurs. If then a nullpointer exception happens later on, they are able to report that location. Runtime overheads for their java-based approach (based on modifications to the Jikes RVM) was about 4% in average only.

Martin Rinard has been putting forward interesting food for thought for a while which just caught my attention. It’s related to the importance of verification tools. In the past many people have evaluated such tools on programs that are in a production state. While this may be successful, exposing bugs in those programs, Martin says that it is likely that those bugs do not matter! After all, the software is in a production state, it is being used. So if the bug was bad, it had been discovered before! What does matter, he says, are all the bugs that have been eliminated before and all the hundreds of man hours that had to be spent on achieving this. I think he is right and I found this very interesting and encouraging for my work on verification tools.

Addendum

If you are  interested in this, you might want to read “Understanding the Value of Program Analysis Tools” by Ciera Jaspan, I-Chin Chen, and Anoop Sharma (CMU/Ebay).