Mark F. Mergen

Implementing jalapeño in Java

Jalapeño is a virtual machine for Java#8482; servers written in Java. A running Java program involves four layers of functionality: the user code, the virtual-machine, the operating system, and the hardware. By drawing the Java / non-Java boundary below the virtual machine rather than above it, Jalapeño reduces the boundary-crossing overhead and opens up more opportunities for optimization. To get Jalapeño started, a boot image of a working Jalapeño virtual machine is concocted and written to a file. Later, this file can be loaded into memory and executed. Because the boot image consists entirely of Java objects, it can be concocted by a Java program that runs in any JVM. This program uses reflection to convert the boot image into Jalapeños object format. A special MAGIC class allows unsafe casts and direct access to the hardware. Methods of this class are recognized by Jalapeños three compilers, which ignore their bytecodes and emit special-purpose machine code. User code will not be allowed to call MAGIC methods so Javas integrity is preserved. A small non-Java program is used to start up a boot image and as an interface to the operating system. Javas programming features — object orientation, type safety, automatic memory management — greatly facilitated development of Jalapeño. However, we also discovered some of the languages limitations.

The Jikes research virtual machine project: building an open-source research community

This paper describes the evolution of the JikesTM Research Virtual Machine project from an IBM internal research project, called Jalapeno, into an open-source project. After summarizing the original goals of the project, we discuss the motivation for releasing it as an open-source project and the activities performed to ensure the success of the project. Throughout, we highlight the unique challenges of developing and maintaining an open-source project designed specifically to support a research community.

Virtualization for high-performance computing

The specific demands of high-performance computing (HPC) often mismatch the assumptions and algorithms provided by legacy operating systems (OS) for common workload mixes. While feature- and application-rich OSes allow for flexible and low-cost hardware configurations, rapid development, and flexible testing and debugging, the mismatch comes at the cost of --- oftentimes significant --- performance degradation for HPC applications.The ubiquitous availability of virtualization support in all relevant hardware architectures enables new programming and execution models for HPC applications without loosing the comfort and support of existing OS and application environments. In this paper we discuss the trends, motivations, and issues in hardware virtualization with emphasis on their value in HPC environments.

801 storage: architecture and programming

Based on novel architecture, the 801 minicomputer project has developed a low-level storage manager that can significantly simplify storage programming in subsystems and applications. The storage manager embodies three ideas: (1) large virtual storage, to contain all temporary data and permanent files for the active programs; (2) the innovation of database storage, which has implicit properties of access serializability and atomic update, similar to those of database transaction systems; and (3) access to all storage, including files, by the usual operations and types of a high-level programming language. The IBM RT PC implements the hardware architecture necessary for these storage facilities in its storage controller (MMU). The storage manager and language elements required, as well as subsystems and applications that use them, have been implemented and studied in a prototype operating system called CPR, that runs on the RT PC. Low cost and good performance are achieved in both hardware and software. The design is intended to be extensible across a wide performance/cost spectrum.

K42: building a complete operating system

K42 is one of the few recent research projects that is examining operating system design structure issues in the context of new whole-system design. K42 is open source and was designed from the ground up to perform well and to be scalable, customizable, and maintainable. The project was begun in 1996 by a team at IBM Research. Over the last nine years there has been a development effort on K42 from between six to twenty researchers and developers across IBM, collaborating universities, and national laboratories. K42 supports the Linux API and ABI, and is able to run unmodified Linux applications and libraries. The approach we took in K42 to achieve scalability and customizability has been successful.The project has produced positive research results, has resulted in contributions to Linux and the Xen hypervisor on Power, and continues to be a rich platform for exploring system software technology. Today, K42, is one of the key exploratory platforms in the DOEs FAST-OS program, is being used as a prototyping vehicle in IBMs PERCS project, and is being used by universities and national labs for exploratory research. In this paper, we provide insight into building an entire system by discussing the motivation and history of K42, describing its fundamental technologies, and presenting an overview of the research directions we have been pursuing.

Experience with K42, an open-source, Linux-compatible, scalable operating-system kernel

K42 is an open-source, Linux-compatible, scalable operating-system kernel that can be used for rapid prototyping of operating-system policies and mechanisms. This paper reviews the structure and design philosophy of K42 and discusses our experiences in developing and using K42 in the open-source environment.

Evolution of storage facilities in AIX Version 3 for RISC System/6000 processors

This paper discusses how the AIX Version 3 storage facilities include features not found in other implementations of the UNIX operating system. Maximum virtual memory is more than 1000 terabytes and is used pervasively to access all files and the meta-data of the file systems. Each separate file system (subtree) of the file name hierarchy occupies a logical disk volume, composed of space from possibly several disks. Database memory (a variant of virtual memory) and other database techniques are used to manage file system meta-data. These features provide the capacity to address large applications and many users, simplified program access to file data, efficient file buffering in memory, flexible management of disk space, and reliable file systems with short restart times.