Abstract Software transactional memory (STM) systems are an attractive environment to evaluate optimistic concurrency. We describe our experience of supporting and optimizing an STM system at both the managed runtime and compiler levels. We describe the design policies of our STM system and the statistics collected by the runtime to identify performance bottlenecks and guide tuning decisions. We present an initial work on supporting automatic instrumentation of the STM primitives for C/C++ and Java programs in the IBM XL compiler and J9 Java virtual machine. We evaluate and discuss the performance of several transactional programs running on our system. Copyright © 2008 John Wiley & Sons, Ltd.

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 DOE's FAST-OS program, is being used as a prototyping vehicle in IBM's 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.

Jalape~no is a virtual machine for Java TM 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~no reduces the boundary-crossing overhead and opens up more opportunities for optimization. To get Jalape~no started, a boot image of a working Jalape ~no 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~no's object format. A special Magic class allows unsafe casts and direct access to the hardware. Methods of this class are recognized by Jalape~no's three compilers, which ignore their bytecodes and emit special-purpose machine code. User code w...

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.

The IBM RT PC implements the necessary features of 801 storage architecture. The upper 4 bits of a 32-bit short address select one of 16 segment registers. A 12-bit segment id from the register replaces the 4 bits to form a 40-bit long virtual address. This creates a single large space of 4096 256M-byte segments. Only the supervisor may load segment registers and may therefore control access to and sharing of segments. A long virtual address is translated to real by an inverted page table, in which each entry contains the virtual page address currently allocated to a real page. Hardware searches the table using chained hashing. If a given virtual address is found in a table entry, the index of that entry is the desired real page address. Table size is related only to real storage size rather than to virtual size as with conventional segment and page tables. The inverted page table includes a transaction locking mechanism. Each entry contains bits to represent read and write locks, for 128-byte lines within the page, granted to the transaction id also in the entry. Lock fault interrupt occurs when storage access by the current transaction (id in a register) is not permitted by locks and id in a table entry. Page protection bits may instead be used when transaction locking is not required.