Turn in this assignment on the course turn-in page by 11:59:59 PM on Feb 16. Note that there is no class on the 16th.
The MARS simulator is an assembler and simulation environment for the MIPS processor architecture. I used MARS in teaching CptS 260 this past fall. The students and I really liked a lot of things about it -- the GUI, breakpoints, memory visualization, the plug-in "tools" for doing interesting things. However, some students reported problems with crashes of the simulator. A quick glance at the code shows that concurrency is used quite a bit and one always wonders whether the concurrency rules have been followed.
Your assignment is to perform a code inspection on Simulator.java, just one of the java files making up MARS. You are looking to see whether the code in this file obeys the rules for proper construction, visibility and safe publication as we have discussed in class. The file can be found at http://www.eecs.wsu.edu/~hauser/cs580/handouts/Simulator.java. The entire MARS package can be downloaded from http://courses.missouristate.edu/KenVollmar/MARS/download.htm but this is not required for this assignment.
You may work in teams of up to three people and I strongly advise you to do so because you will learn a whole lot more if you are able to discuss your thinking with someone.
What to turn in: a report (per team) specifically identifying any problems that you found in the code related to construction and publication. Specific identification includes names of problematic variables, line numbers and code fragments where things are done wrong, the specific nature of the problem, etc. The idea is that with your report and the source code in hand a reader should be able to easily go to the locations where you identify problems and understand why they are problems. Based on what you find suggest an inspection plan for the remainder of the MARS code -- what would you be on the lookout for.
Grad students:In addition to the above, write a couple of paragraphs analyzing the feasibility of automating such inspections. Take a look at the tool FindBugs (findbugs.sourceforge.net) for an example of the kind of tool that I have in mind. You should identify some promising approaches to the problem as well as obstacles in the way of constructing such a tool. If you find an existing tool that does this analysis so much the better. (FindBugs does not appear to have this capability yet.)