I’m at PLDI right now. Toronto is nice, the tutorials on Sunday were great, and so were most of the paper sessions. The downsides are the lack of outlets in the conference rooms, and the virtually complete lack of WLAN in the entire hotel (there is wired LAN in the hotel rooms).
In the evenings, I’ve been profiling DrJava to find out why our DrJava tests on Hudson was thrashing so much [1]. I noticed that [cc lang=”java” inline=”true”]MainFrameTest[/cc] was currently using about 650 MB or heap space. No wonder our 512 MB server had trouble. I couldn’t really tell what was going on. YourKit really only showed me that there were lots of [cc lang=”java” inline=”true”]HashMap.Entry[/cc] instances being created. They seemed to have something to do with tables and the Preferences window.
I checked out several old revisions, going as far back as 4694 [2] from the end of 2008. Its [cc lang=”java” inline=”true”]MainFrameTest[/cc] needed only about 300 MB. Through divide and conquer, I realized that the switch from [cc lang=”java” inline=”true”]JList[/cc] to [cc lang=”java” inline=”true”]JTable[/cc] for [cc lang=”java” inline=”true”]Vector*OptionComponents[/cc] added a lot of bloat, at least in the tests. This was most dramatic for the [cc lang=”java” inline=”true”]VectorKeyStrokeOptionComponents[/cc]
I started working on rolling the changes for keystrokes back. I was able to reduce memory consumption to about 400 MB. but the list-based GUI is just so ugly compared to the newer tables.
Fortunately, just before I had left for PLDI I had asked IT to add more swap space to our Hudson server, and that made the whole problem a non-issue: What took about two hours when Hudson was thrashing now takes less than 15 minutes.
I don’t think I’ll commit these changes. I’ll just file it under “can be done if necessary.”
