The Java Virtual Machine (JVM) has a novel and powerful mechanism to support lazy, dynamic class loading according to user-definable policies. Class loading directly impacts type safety, on which the security of Java applications is based. Conceptual bugs in the loading mechanism were found in earlier versions of the JVM that lead to type violations. A deeper understanding of the class loading mechanism, through such means as formal analysis, will improve our confidence that no additional bugs are present. The work presented in this paper provides a formal specification of (the relevant aspects of) class loading in the JVM and proves its type safety. Our approach to proving type safety is different from the usual ones since classes are dynamically loaded and full type information may not be statically available. In addition, we propose an improvement in the interaction between class loading and bytecode verification, which is cleaner and enables lazier loading.

Abstract. We believe that fundamental to the establishment of a grid computing framework where all (not just large organizations) are able to effectively tap into the resources available on the global network is the establishment of trust between grid application developers and resource donors. Resource donors must be able to trust that their security, safety, and privacy policies will be respected by programs that use their systems. In this paper, we present a novel solution based on the notion of certified code that upholds safety, security, and privacy policies by examining intrinsic properties of code. Certified code complements authentication and provides a foundation for a safe, secure, and efficient framework that executes native code. We describe the implementation of such a framework known as the ConCert software. 1 Introduction In recent years, numerous organizations have been vying for donated resources for their grid applications. Potential resource donors are inundated with worthwhile grid projects such as discovering a cure for AIDS, finding large prime numbers, and searching for extraterrestrial intelligence. Part of the difficulty in obtaining resources is establishing trust between the grid application developer and the resource donors. Because resource donors often receive little or no direct reward for their contributions, they demand assurances of safety, security, and privacy to protect themselves from malicious as well as simply unreliable software. In an ideal grid framework, as proposed in Legion [18], users are provided the abstraction of a single virtual machine that automatically distributes work and gathers results. In such a framework, this issue is even more salient because the exchange of code happens automatically.

The Java programming language was designed for portability and safe code distribution, not for fault-tolerance. We modify the Sun JDK1.2 to provide transparent fault-tolerance for many Java applications under the crash failure model. Our approach is to log non-deterministic events at the JVM interface using a primary-backup architecture. In particular, we identify the sources of non-determinism in the JVM due to asynchronous exceptions and multi-threaded access to shared data, as well as the non-determinism present at the native method interface. We analyze the overhead introduced in our system by each of these sources of non-determinism and compare the performance of dierent techniques for handling multi-threading.

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].

We present JavaMod, a module language where components of modules are Java classes. The operators for composing modules are a slightly adapted version of those of CMS, a simple and powerful calculus of modules previously dened by the authors which is generic w.r.t. the underlying core calculus. The challenge we wanted to face was to apply this very general framework for module composition to the difficult case where module components are Java classes. The result is that we are able to obtain a true module language which is extremely flexible and allows to express (without enriching the core level, that is, the Java language), for instance, generic types as in Pizza and GJ, mixin classes (that is, heir classes parametric in the superclass) and mutually recursive class definitions split in independent modules.

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.

Overloading allows several function definitions for the same name, distinguished primarily through different argument types, and is typically resolved at compile-time. Inheritance allows subclasses to define more special versions of the same function, and is typically resolved at run-time. Modern object-oriented languages incorporate both features, usually in a type-safe manner. However, the combination of these features sometimes turns out to have surprising, and even counterintuitive, effects. We discuss why we consider these effects inadequate, and suggest alternatives. We explore the design space by isolating the main issues involved and analysing their interplay and suggest a formal framework describing static overloading resolution and dynamic function selection, abstracting from other language features. We believe that our framework clarifies the thought process going on at language design level. In particular we introduce a notion of soundness and completeness of an overloading res...

The Linux kernel currently supports a single user space page size, usually the minimum dictated by the architecture. This paper describes the ongoing modifications to the Linux kernel to allow applications to vary the size of pages used to map their address spaces and to reap the performance benefits associated with the use of large pages.

This paper overviews an ongoing project aimed at developing an automatic generator of Java Card applets from higher-level spec(ification)s written in a domain-specific language called "SmartSlang ". The generator is based on Specware, a system for the formal specification and refinement of software. The applet generator translates a SmartSlang spec into the logical language of Specware, re-expresses the translated spec in terms of Java Card concepts via a series of refinement steps using Specware's machinery, and generates Java Card code from the refined spec. The Java Card concepts used for refinement and code generation are captured as a shallow embedding of the Java Card language and API in the logic of Specware. Since proofs are associated to refinement steps, the applet generator produces a machine-processable proof tree along with the code, enabling the correctness of the generated code (with respect to the spec) to be checked independently from the applet generator, via a smaller and simpler applet checker to be also developed in this project.

The combination of overloading and inheritance in Java introduces questions about function selection, and makes some function calls ambiguous. We believe that the approach taken by Java designers is counterintuitive. We explore an alternative, and argue that it is more intuitive and agrees with the Java rules for the cases where Java considers the function calls unambiguous, but gives meaning to more calls than Java does.