Here's a C2 starter project to consider. It's a major cleanup that will be needed for Project Sumatra, when we need to simultaneously generate code for 2 ISAs (CPU + GPU).

(Note: Although this is very large for a starter project, it can be attempted with little or no prior knowledge of C2. It is likely to introduce the intrepid programmer to many aspects of the C2 backend.)

Consider how ADLC generates C++ code and data. It generates static tables and code under the type Matcher. As a first step toward dual ISA support, we need to make that C++ code and data be instance-specific, so that all queries go through a Matcher object instead of the Matcher:: namespace. (It is still OK to make the tables or functions static, as long as they are private to one instance of the Matcher.)

The goal is to have 2 Matchers, one for the CPU and one for the GPU. Also, the GPU matcher might be selected from a set of N GPU ISA candidates compiled into one JVM. Or (who knows) it might be dlopened.

An initial goal of having the ability to generate code for 2 ISAs - one for CPU and the other for GPU is a good start to iron out issues involved. Bharadwaj Yadavalli suggests that we might want to support a generic framework where in code can be generated for more than 2 ISAs. Think of a server machine with a combination of APU (integrated GPU + CPU a la AMD's offering), and more than one discrete GPUs. Vendors may be offering heterogeneous cores, where the GPU cores on the die might not be of the same ISA as the discrete GPUs. So a flexible runtime selectable Matcher, loaded via dlopen, might be a good long term vision to shoot for.