Atomic instructions atomically access and update one or more memory locations. Because they do not incur the overhead of lock acquisition or suspend the executing thread during contention, they may allow higher levels of concurrency on multiprocessors than lock-based synchronization. Wait-free data structures are an important application of atomic instructions, and extend these performance benefits to higher level abstractions such as queues. In type-unsafe languages such as C, atomic instructions can be expressed in terms of operations on mem- ory addresses. However, type-safe languages such as Java do not allow manipulation of arbitrary memory locations. Adding support for atomic instructions to Java is an interesting but important challenge. In this paper we consider several ways to support atomic instructions in Java. Each technique has advantages and disadvantages. We propose idiom recognition as the technique we feel has the best combination of expressiveness and simplicity. We describe techniques for recognizing in- stances of atomic operation idioms in the compiler of a Java Virtual Machine, and converting such instances into code utilizing atomic ma- chine instructions. In addition, we describe a runtime technique which ensures that the semantics of multithreaded Java[11] are preserved when atomic instructions and blocking synchronization are used in the same program. Finally, we present benchmark results showing that for concur- rent queues, a wait-free algorithm implemented using atomic compare- and-swap instructions yields better scalability on a large multiprocessor than a queue implemented with lock-based synchronization.

We explore advances in Java Virtual Machine (JVM) tech- nology along with new high performance I/O libraries in Java 1.4, and find that Java is increasingly an attractive platform for scientific cluster- based message passing codes. We report that these new technologies allow a pure Java implementa- tion of a cluster communication library that performs competitively with standard C-based MPI implementations.

We evaluate the impact of programming language features on the performance of parallel applications on modern parallel architectures, particularly for the demanding case of sparse integer codes. We compare a number of programming languages (Pthreads, OpenMP, MPI, UPC, Global Arrays) on both shared and distributed-memory architectures. We find that language features can make parallel programs easier to write, but cannot hide the underlying communication costs for the target parallel architecture. Powerful compiler analysis and optimization can help reduce software overhead, but features such as fine-grain remote accesses are inherently expensive on clusters. To avoid large reductions in performance, language features must avoid interfering with compiler optimizations for local computations.

A proxy object is a surrogate or placeholder that controls access to another target object. Proxies can be used to sup- port distributed programming, lazy or parallel evaluation, access control, and other simple forms of behavioral reflec- tion. However, wrapper proxies (like futures or suspensions for yet-to-be-computed results) can require significant code changes to be used in statically-typed languages, while prox- ies more generally can inadvertently violate assumptions of transparency, resulting in subtle bugs. To solve these problems, we have designed and imple- mented a simple framework for proxy programming that employs a static analysis based on qualifier inference, but with additional novelties. Code for using wrapper proxies is automatically introduced via a classfile-to-classfile trans- formation, and potential violations of transparency are sig- naled to the programmer. We have formalized our analysis and proven it sound. Our framework has a variety of appli- cations, including support for asynchronous method calls re- turning futures. Experimental results demonstrate the bene- fits of our framework: programmers are relieved of managing and/or checking proxy usage, analysis times are reasonably fast, overheads introduced by added dynamic checks are neg- ligible, and performance improvements can be significant. For example, changing two lines in a simple RMI-based peer- to-peer application and then using our framework resulted in a large performance gain.

We have replicated the experiments of Cecchet et al. de- tailed in Performance and Scalability of EJB Applications at OOPSLA '02. We report on our experiences configuring, deploying and tuning Enterprise software. We found a num- ber of configuration problems that suggest that some of the conclusions of the original work were wrong.

Much research has been done on techniques to teach students how to program. However, it is usually difficult to quantify exactly how students work. Instructors typically only see students' work when they submit their projects or come to office hours. Another common problem in introductory programming courses is that student code is only subjected to rigorous testing once it has been submitted. Both of these problems can be viewed as a lack of feedback between students and instructors.

We have built an Eclipse plugin to address this lack of feedback. The plugin has two main functions. First, it captures, to a central CVS repository, the complete state of a student's project every time he or she saves, adds, or removes a file. This produces a fine-grained history of the evolution of each student's project. Second, the plugin allows the student to submit his or her project to a central server. The submit server automatically compiles and performs limited testing of the student's submission, providing feedback on how close the project is to fulfilling the project requirements.

Our goal is to provide instructors and researchers with far more detailed information about how students learn and work, and provide feedback to students that will help them focus on achieving the goals of the projects we assign.

Most computer science educators hold strong opinions about the ``right'' approach to teaching introductory level programming. Unfortunately, we have comparatively little hard evidence about the effectiveness of these various approaches because we generally lack the infrastructure to obtain sufficiently detailed data about novices' programming habits.

To gain insight into students' programming habits, we developed Marmoset, a project snapshot and submission system. Like existing project submission systems, Marmoset allows students to submit versions of their projects to a central server, which automatically tests them and records the results. Unlike existing systems, Marmoset also collects fine-grained code snapshots as students work on projects: each time a student saves her work, it is automatically committed to a CVS repository.

We believe the data collected by Marmoset will be a rich source of insight about learning to program and software evolution in general. To validate the effectiveness of our tool, we performed an experiment which found a statistically significant correlation between warnings reported by a static analysis tool and failed unit tests.

To make fine-grained code evolution data more useful, we present a data schema which allows a variety of useful queries to be more easily formulated and answered.

Using static analysis to detect memory access errors, such as null pointer dereferences, is not a new problem. However, much of the previous work has used rather sophisticated analysis techniques in order to detect such errors.

In this paper we show that simple analysis techniques can be used to identify many such software defects, both in production code and in student code. In order to make our analysis both simple and effective, we use a non-standard analysis which is neither complete nor sound. However, we find that it is effective at finding an interesting class of software defects.

We describe the basic analysis we perform, as well as the additional errors we can detect using techniques such as annotations and inter-procedural analysis.

In studies of both production software and student projects, we find false positive rates of around 20% or less. In the student code base, we find that our static analysis techniques are able to pinpoint 50% to 80% of the defects leading to a null pointer exception at runtime.

Various static analysis tools will analyze a software artifact in order to identify potential defects, such as misused APIs, race conditions and deadlocks, and security vulnerabilities. For a number of reasons, it is important to be able to track the occurrence of each potential defect over multiple versions of a software artifact under study: in other words, to determine when warnings reported in multiple versions of the software all correspond the same underlying issue. One motivation for this capability is to remember decisions about code that has been reviewed and found to be safe despite the occurrence of a warning. Another motivation is constructing warning deltas between versions, showing which warnings are new, which have persisted, and which have disappeared. This allows reviewers to focus their efforts on inspecting new warnings. Finally, tracking warnings through a series of software versions reveals where potential defects are introduced and fixed, and how long they persist, exposing interesting trends and patterns.

We will discuss two different techniques we have implemented in FindBugs (a static analysis tool to find bugs in Java programs) for tracking defects across versions, discuss their relative merits and how they can be incorporated into the software development process, and discuss the results of tracking defect warnings across Sun's Java runtime library.

Two important questions regarding automated submission and testing systems are: What kind of feedback should we give students as they work on their programming assignments, and how can we study in more detail the programming assignment development process of novices?

To address the issue of feedback, Marmoset provides students with limited access to the results of the instructor's private test cases using a novel token-based incentive system. This both encourages students to start their work early, and to think critically about their work. In addition, because students submit their work early, instructors and TAs can monitor all students' progress on test cases. This allows instructors to identify challenging test cases early and either update the project specification or spend additional time in lecture or lab sessions covering difficult material.

To study and better understand the development process of students, Marmoset can be configured to transparently capture snapshots to a central repository every-time students save their files. These detailed development histories offer a unique, detailed perspective of each student's progress on a programming assignment, from the first line of code written and saved all the way through the final edit before the final submission. This type of data has proven extremely valuable for various uses, from mining new bug patterns to evaluating existing bug-finding tools.

In this paper, we describe our initial experiences using Marmoset in several introductory computer science courses, from the perspectives of both instructors and students. We also describe some initial research results from analyzing the student snapshot database.

Many project submission and testing systems have been de- veloped. These systems can be beneficial for both students and instructors: students benefit from having automatic feedback on which parts of their projects work correctly and which parts still need work, while instructors benefit from real-time feedback on the progress of individual students and the class as a whole. A limitation of traditional project submission and test- ing systems is that they only track the project versions that students explicitly submit; what students are doing between submissions remains shrouded in mystery. Based on expe- rience, we know that many students who hit a stumbling block resort to unproductive trial-and-error programming. As instructors, we would like to know what these stumbling blocks are. To help understand how students work, we developed Mar- moset, a project submission, testing, and snapshot system. The system has two novel features. First, it employs a token-based incentive system to encourage students to start work early and to think critically about their work. Second, Marmoset can be configured to use CVS to transparently capture a project snapshot every time students save a file. The detailed development history thus captured offers a fine- grained view of each student's progress. In this paper, we describe initial experiences with Mar- moset, from the perspectives of both instructors and stu- dents. We also describe some initial research results from analyzing the student snapshot database.