Skip to end of metadata
Go to start of metadata

This page captures project proposals for Jikes RVM for the Google SoC 2010. The page organizes projects into the major components of Jikes RVM they effect, these are: Garbage Collector (MMTk), Compilers and the Runtime System. We also have other projects that relate to Jikes RVM.

The Jikes RVM GSoC 2010 page page includes links to the student application template and GSoC User Guide which explains how to apply.

APPLICATION WINDOW: 19:00 UTC, 29 March 2010 - 19:00 UTC, 9 April 2010

Garbage Collector (MMTk) proposals

Garbage Collection Visualization

The GCspy framework has become slightly out-of-date and needs improving. RVM-388

Interested mentors: Richard Jones

On-the-fly Garbage Collector

MMTk has a basic concurrent garbage collector. This project would implement a classic on-the-fly collector.

Interested mentors: Steve Blackburn and Daniel Frampton

The Compressor Mark-Compact Garbage Collector

This project would add the Compressor Mark-Compact algorithm to MMTK's suite of collectors, starting with a stop-the-world implementation. RVM-401

Interested mentors: Richard Jones

The MMTk test harness tools

There are several possible projects here:

  • Implement a weak memory model, and/or tools for checking data races in
    the simulated memory.
  • Implement a mechanism for running Java applications through the harness.
    The most tractable approach might be to use bytecode rewriting to manage
    the simulated MMTk heap as a shadow of the Java heap.
  • New invariants/checks/tests to detect errors in GC implementations. This could be motivated by a GC implementation project (eg MC^2).

Interested mentors: Robin Garner

Compiler proposals

Port of the opt compiler to x86_64

The opt compiler is completely ported to ppc64, so this would require a similar piece of work for the x86 code generator. If the baseline compiler is working on x86_64, then the assembler work has already been done, so porting the opt compiler actually should be entirely doable by someone who is comfortable with lowlevel x86/x86_64 debugging.

Improved register allocator for x86 and x86_64

The current linear scan allocator works best with register rich architectures. This project would look at providing a better allocator for architectures that provide fewer registers.

Interested mentors: Tony Hosking, ELiot Moss


The CoGenT project at UMass aims to make it easier to generate compiler components given descriptions of compiler IRs and of target machines. One of its tools is a generator of instruction selectors; we call it GIST. We have GIST somewhat working to generate the target dependent part of the Jikes RVM Baseline compiler.

  • Rounding out automatic generation of the instruction selector ("code generator") for the
    Baseline compiler.
  • Developing automatic generation of BURS rules (which are quite similar to the patterns that
    GIST finds anyway) for the Jikes RVM Opt compiler.

We would first create code generators for existing targets (x86 and PowerPC) to validate the work, and could then proceed to new target (64-bit x86, and look at new platforms, though a complete platform port has somewhat broader scope).

  • Generating peephole optimizers using GIST is also a possibility, though at this stage perhaps more challenging.
  • Creating a quality "generic" register allocator for the Opt compiler that a GIST-related tool could target would be an excellent project. This could work along the lines of "A Generalized Algorithm for Graph-Coloring Register Allocation" by Smith, Ramsey, and Holloway (PLDI, 2004), possibly with coalescing as well.
  • It would also be attractive to follow a similar plan for generating linear-scan register allocators for the Jikes RVM Opt compiler from machine descriptions.
  • Finally, GIST, augmented with suitable cost models for each target, could be used to generate
    instruction schedulers automatically.

Any of these projects would advance both Jikes RVM and the CoGenT tools.

Interested mentors: Eliot Moss and Chip Weems

Object splitting

This project involves a profiling infrastructure to measure field hotness, changes to the JIT compilers to deal with accesses to cold fields, and changes to the garbage collector(s) to allocate cold fields out of the way of hot objects. Given such an infrastructure, future work could then study alternative implementations, or ideas such as the lazy allocation of the cold fields.

Interested mentor: Matthias Hauswirth

Runtime Services

Extending VM Magic

Jikes RVM uses an extended variant on Java, which includes special types and intrinsic methods that are essential to the internals of the VM but that cannot be expressed in regular Java. For example, we implement an Address type, which corresponds roughly to C's void*. This type has a magical size (the size of an architectural word), and magic semantics (for example you can de reference it and even prefetch on it). None of these semantics could be implemented with regular Java.

An important feature of VM Magic which has not been properly implemented is compound types (roughly equivalent to C's struct types). Such types would be very useful within Jikes RVM because they represent compound types without the overhead and restriction of an object header. This project will implement compound types for Jikes RVM.

A useful reference is the 2009 paper describing VM Magic, including some of these unimplemented features (available here).

Interested mentors: Steve Blackburn and Daniel Frampton

Support (a subset of) the JVM Tool Interface (JVMTI)

The JVMTI is large. This project would concentrate on providing support for GC-related JVMTI functionality.

Suggested by: Suriya Subramanian
Interested mentors: Steve Blackburn and Richard Jones

Support for jmap, jhat, jstack

This project would provide support for JVM debugging facilities such as jmap which dumps an application's heap, jhat which examines the dumped heap, and jstack which dumps an application's stack.

Suggested by: Suriya Subramanian
Interested mentors: Steve Blackburn

Integration with Maxine VM's Inspector

The Maxine Inspector plays many roles:

  • object, class, and method browser;
  • code views include disassembled machine code, disassembled bytecode, and source;
  • low-level debugger (imagine gdb or dbx) with visual displays of threads, registers, stacks, * stack frames, thread local values, breakpoints, memory watchpoints, etc.;
  • intermediate representation debugger; etc.

This project would provide an interface to the Inspector.

Suggested by: Suriya Subramanian
Interested mentors: Steve Blackburn

Probes for DTrace

DTrace allows user-space code to add so-called USDT (User-level Statically Defined Tracing) probes (see example below). It would be useful to be able to use DTrace to correlate system behavior (e.g. scheduling, thread migration, ...) with behavior of the Jikes RVM (e.g. locking, GC, ...).

Interested mentors: Matthias Hauswirth

Other proposals relating to Jikes RVM

Get the new DaCapo benchmarks (dacapo-9.12-bach) running on Jikes RVM.

A number of the new DaCapo benchmarks don't run on Jikes RVM. This project would be to figure out why each failing program is failing and get make fixes to Jikes RVM and/or its class libraries to make the programs work. This would be of significant value to the Jikes RVM research community.

Interested mentors: Steve Blackburn

  • No labels