Projects

XJ: Hybrid STM/HTM Nested Transactions for Java

XJ is a dialect of java that support various forms of transactions in both STM and HTM. It supports closed nested, open nested, boosted transactions as well as flat nested transactions. It serves as a language and framework to compare various implementations of transactional programming. As shown below XJ comprise of a compiler, a dynamic bytecode rewriting framework, a runtime library and a modified JVM to support HTM.

The XJ compiler is based on OpenJDK's javac, and helps us handle the XJ syntax and report errors accordingly. The XJ compiler emits standard bytecode which enables the STM to run on an unmodified JVM.

The load-time bytecode rewriter is a Java agent built using the Java Virtual Machine Tool Interface (JVMTI). It runs as a separate process, and can rewrite all loaded classes (including those loaded by the bootstrap class loader). The framework is based on ASM.

The run-time library provides the dynamic support needed for transactional execution. It supports both closed and open nested transactions, running under HTM or STM simultaneously, as well as boosting.

HTM support relies on the Intel TSX instructions. Thus running HTM requires a modified JVM, this is achieved by modifying the interpreter and the C1 and C2 compilers of OpenJDK's hotspot compiler.

Multi-tenant JVM

This work was done as part of my Internship at IBM Research Austin, Tx, where I was involved in building a multitenant JVM. We chose to built this functionality into OpenJDK. The modifications needed were quite intrusive, as most of the components were aware of each other. We introduced a tenant context that holds all the information needed for each tenant. Each tenant in the system was given its own heap space, while major components in the system were then modified to be able to serve any tenant, rather than the whole system. Examples of such components are the compiler and garbage collector, which we made it into a service where it can service a job from any tenant running on the system.

ILToC: .NET intermediate language (MSIL) to C translator

ILToC was a framework to translate .NET intermediate language (MSIL) to C. I worked on this while I was in Intern at Microsoft research in Redmond, WA. This project was more or less a translator rather than a compiler. The translation though had to deal with tricky bits of the language such as structured exception handling, virtual method invocation, generics, locking and threading and other basic infrastructure.

X10 Serialization protocol

I had the privilege of working with the X10 language group while I was an intern at IBM T. J. Watson Research Center , NY. X10 compiles ti either java or C++ and you could have different places running on either one of them. The goal of the project was to enable them to communicate with each other in an interoperable manner, thus they could not use standard Java serialization. I designed and implemented a custom serialization protocol. X10 used polyglot as there compiler, I made changes to the code generation component, that generated code for serialization in an interoperable manner.

X10 on the e single-chip cloud computer (SCC)

The Single-Chip Cloud Computer (SCC) experimental processor is a 48-core ‘concept vehicle’ created by Intel Labs as a platform for many-core software research. It supported a native message passing API known as RCCE (pronounced “rocky”). On the other hand the X10 run-time supported various forms of communication such as sockets and MPI. We are interested to see how X10 (which is a natural fit for the SCC) would scale on the SCC. We implemented a communication later based on RCCE and compared its performance to the MPI based implementation of X10.