JCrasher is an automatic robustness testing tool for Java code. JCrasher examines the type information of a set of Java classes and constructs code fragments that will create instances of different types to test the behavior of public methods under random data. JCrasher attempts to detect bugs by causing the program under test to “crash”, that is, to throw an undeclared runtime exception. Although in general the random testing approach has many limitations, it also has the advantage of being completely automatic: no supervision is required except for off-line inspection of the test cases that have caused a crash. Compared to other similar commercial and research tools, JCrasher offers several novelties: it transitively analyzes methods, determines the size of each tested method’s parameter-space and selects parameter combinations and therefore test cases at random, taking into account the time allocated for testing; it defines heuristics for determining whether a Java exception should be considered a program bug or the JCrasher supplied inputs have violated the code’s preconditions; it includes support for efficiently undoing all the state changes introduced by previous tests; it produces test files for JUnit—a popular Java testing tool; and can be integrated in the Eclipse IDE. key words: software testing, test case generation, random testing, Java, state re-initialization 1.

Abstract. We extend our correspondence between evaluators and abstract machines from the pure setting of the λ-calculus to the impure setting of the computational λ-calculus. We show how to derive new abstract machines from monadic evaluators for the computational λ-calculus. Starting from (1) a generic evaluator parameterized by a monad and (2) a monad specifying a computational effect, we inline the components of the monad in the generic evaluator to obtain an evaluator written in a style that is specific to this computational effect. We then derive the corresponding abstract machine by closure-converting, CPS-transforming, and defunctionalizing this specific evaluator. We illustrate the construction with the identity monad, obtaining yet again the CEK machine, and with a lifted state monad, obtaining a variant of the CEK machine with error and state. In addition, we characterize the tail-recursive stack inspection presented by Clements and Felleisen at ESOP 2003 as a lifted state monad. This enables us to combine the stackinspection monad with other monads and to construct abstract machines for languages with properly tail-recursive stack inspection and other computational effects. The construction scales to other monads—including one more properly dedicated to stack inspection than the lifted state monad—and other monadic evaluators. Keywords. Lambda-calculus, interpreters, abstract machines, closure conversion, transformation into continuation-passing style (CPS), defunctionalization, monads, effects, proper

Although the C-based interpreter of Python is reasonably fast, implementations on the CLI or the JVM platforms offers some advantages in terms of robustness and interoperability. Unfortunately, because the CLI and JVM are primarily designed to execute statically typed, object-oriented languages, most dynamic language implementations cannot use the native bytecodes for common operations like method calls and exception handling; as a result, they are not able to take full advantage of the power offered by the CLI and JVM. We describe a different approach that attempts to preserve the flexibility of Python, while still allowing for efficient execution. This is achieved by limiting the use of the more dynamic features of Python to an initial, bootstrapping phase. This phase is used to construct a final RPython (Restricted Python) program that is actually executed. RPython is a proper subset of Python, is statically typed, and does not allow dynamic modification of class or method definitions; however, it can still take advantage of Python features such as mixins and first-class methods and classes. This paper presents an overview of RPython, including its design and its translation to both CLI and JVM bytecode. We show how the bootstrapping phase can be used to implement advanced features, like extensible classes and generative programming. We also discuss what work remains before RPython is truly ready for general use, and compare the performance of RPython with that of other approaches.

Abstract. Java is normally compiled to bytecode, which is verified and then executed by the Java Virtual Machine. Bytecode produced via compilation must pass verification. The main cause of complexity for bytecode verification is subroutines, used by compilers to generate more compact code. The techniques to verify subroutines proposed in the literature reject certain programs produced by mundane compilers or are otherwise difficult to realize within an implementation of the Java Virtual Machine. This paper presents a novel technique which is very simple to understand, implement, and prove sound. It is also very powerful: the set of accepted programs has a simple characterization which most likely includes all code generable by current compilers and which enables future compilers to make more extensive use of subroutines. 1 Java Bytecode Java [2, 11] is normally compiled to a platform-independent bytecode language, which is executed by the Java Virtual Machine (JVM) [18]. This bytecode language features intra-method subroutines, used by Java compilers to generate more compact code [18, Sect. 7.13].

Bytecode verification is the main mechanism to enforce type safety in the Java Virtual Machine. Since Java security is based on type safety, inadequacies and ambiguities in the official specification of bytecode verification can lead to incorrect implementations where security can be broken. This paper analyzes the specification and proposes concrete improvements. The goal of this work is to increase the understanding, assurance, and usability of the Java platform.

We present a runtime environment that implements a Java Virtual Machine by co-execution between the different functional units of the heterogeneous Cell multiprocessing platform. Our approach uses the Cell’s scratchpad memory as a software-controlled cache and contains an automatic software-based memory management system for instruction and data caching. Profiling shows a cache hit rate of above 90 % for the instruction cache and above 74 % for the data cache.

We present the design and implementation of a highly scalable and easily deployed middleware system that provides performance-isolated execution environments for client and server application functionality. The Java Active Extensions system allows clients or servers to “extend ” their operation by hosting portions of their codes, called extensions, at network vantage points for improved performance and reliability, and by providing them with qualities of service in the form of rate-based resource reservations. This is especially useful for wireless resource-limited clients, which can remotely locate filters, caches, monitors, buffers, etc., to act on their behalf and improve interactions with servers. Servers also benefit by moving some of their services close to their clients (e.g., those near a common base station) to reduce latency and improve bandwidth. In both cases, the client’s or server’s extended functionality executes with a specified fraction of the (remote) system’s processor. The system design is based on a scalable distributed architecture that allows for incremental hardware growth, and is highly deployable as it runs entirely at user level, including its rate-based scheduling system.

Computational grids have an enormous potential to provide compute power. However, this power remains largely unexploited today for most applications, except trivially parallel programs. Developing parallel grid applications simply is too difficult. Grids introduce several problems not encountered before, mainly due to the highly heterogeneous and dynamic computing and networking environment. Furthermore, failures occur frequently, and resources may be claimed by higher priority jobs at any time. In this paper, we solve these problems for an important class of applications: divide-andconquer. We introduce a system called Satin that simplifies the development of parallel grid applications by providing a rich high-level programming model that completely hides communication. All grid issues are transparently handled in the run time system, not by the programmer. Satin’s programming model is based on Java, features spawn-sync primitives and shared objects, and uses asynchronous exceptions and an abort mechanism to support speculative parallelism. To allow an efficient implementation, Satin consistently exploits the idea that grids are hierarchically structured. Dynamic load-balancing is done with a novel cluster-aware scheduling algorithm that hides the long wide-area latencies by overlapping them with useful local work.

A systematic method of compiling lazy functional programs based on the Spineless Tagless G-machine (STGM) is presented for the Java Virtual Machine (JVM). A new specification of the STGM, which consists of a compiler and a reduction machine, is presented; the compiler translates a program in the STG language, which is the source language for the STGM, into a program in an intermediate language called L-code, and our reduction machine reduces the L-code program into an answer.

Abstract—Decompilation of Java bytecode is the act of transforming Java bytecode to Java source code. Although easier than that of decompilation of machine code, problems still arise in Java bytecode decompilation. These include type inference of local variables and exception-handling. Since the last such evaluation (2003) several new commercial, free and open-source Java decompilers have appeared and some of the older ones have been updated. In this paper, we evaluate the currently available Java bytecode decompilers using an extension of the criteria that were used in the original study. Although there has been a slight improvement since this study, it was found that none passed all the tests, each of which were designed to target different problem areas. We give reasons for this lack of success and suggest methods by which future Java bytecode decompilers could be improved. Keywords-java; bytecode; decompilation; I.