As always, the welcome address for the ICSE conference included the submission/acceptance reports… and this year ICSE came in at 15% acceptance… pretty strong accept rate as always. One thing that the speaker pointed out that I hadn’t really realized earlier is that this includes all “submissions,” no matter what those submissions where. Later in the slides, he pointed out that some 14 of the original submissions were thrown out for being off-topic or because they “were just power-point slides and the such.” (I’m impressed that anyone bothers to submit presentation slides as research papers for such a big conference… but I shouldn’t be surprised by anything anymore)
Below I’ve listed some of the paper presentations that I found interesting. Note that I say interesting not good/great. Before I say that any of these items are really great, I’ll read the paper first. So let’s just say that these papers are candidates to be good papers…
Time will Tell: Fault Localization using Time Spectra
Authors: Cemal Yilmaz, Amit Paradkar, Clay Williams (IBM T.J. Watson Labs)
This idea and the presentation were both rather interesting. The presenter claimed that method execution time could be used to localize defects in source code. The technique operated in two phases: 1) Using passing test cases, execution times are correlated with the execution times of other methods, then 2) a failing test case is run and then look for a execution time that is outside the coloration model.
When the time for questions came around, I think some people forgot that the technique was only for localizing errors that were known to exist rather than detecting errors outright. This lead to questioning how the technique compared to stack traces (complementary, esp. once the trace doesn’t immediately work) and questions about the specific technique for correlation (anything will work at first to prove the concept, better techniques can be used later).
Precise Memory Leak Detection for Java Software Using Container Profiling
Authors: Guoqing Xu, Atanas Rountev
At first, I found most of this presentation rather obvious. The idea that Java leaks memory (via objects) is well known. In order to leak them, they have to still be referenced, but not directly. The reference has to be somewhat anonymous, otherwise the object is “owned” by someone which (when applied recursively) means that it’s either active or a candidate for GC. The primary way to keep an object around without “owning” it is via some sort of container. (In my practice, the biggest memory leak in Java is actually String.subString()’s implementation detail, but that’s another topic)
Ok, so once we assume that most memory leaks are due to objects loosing their identity and ownership by being placed in a container, then this paper proposes a technique for figuring out which container in the application is holding the leaking objects. Basically, containers are ranked based on how much memory they (and their contents) consume through a deep traversal of the object graph. They are also ranked based on a staleness metric (see the paper for exact details) which measures how long an object hangs out in a container after it retrieved (via get).
On the surface it seems like a reasonable idea, but in practice I would expect many cases where containers are working as designed when they cache large objects for long periods of time. If (and how) the authors account for this will be interesting to find out.
