Eric Bodden

4°C

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!

McGill just started a new fund raising campaign because the last one (which brought them 350M$!!! from private donors – thanks!) just ran out. They made a funny promo video, of course. Have a look…

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.

If you look at the top right you will see my new weather icon. It always shows the current weather conditions here in Montreal. It took a while to get it display nicely in Internet Explorer (I am not sure who to blame: IE apparently moves following text to under the element, if an element is positioned with “float: right;”, while Firefox doesn’t.) and it’s still not perfect but it works for me.

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