{compiler, classlib, MMTk, infrastructure...}

links to related projects, academic papers, etc

skills that the student should have and/or needs to acquire during the project

a difficulty estimate for the project, e.g. easy, medium, difficult

your name and a contact link or "TBD" if you can't mentor

classlib, MMTk, threading, compiler

The Java Management Extensions provide a way to monitor and manage Java Virtual machines. The Jikes RVM can collect significantly more profiling data and runtime statistics than an average JVM as a result of it being focussed on research activities. These statistics would ideally be exported using JMX and could potentially provide a standard mechanism for monitoring the performance and health of the virtual machine and its components.

As a first step, students should focus on laying groundwork for a suitable implementation of the API:

• Update the JMX code from GSoC 2007 (written by Andrew John Hughes) to work with the current Jikes RVM
• Implement all the parts of the API that are required
• Write automated tests that can be integrated into our test frameworks

After that has happened, students should implement the optional parts of the API and Jikes RVM-specific features. The exact set of features will need to be discussed with the community at the appropriate time.

Blog post about JMX with links to further documentation

Our bugtracker entry for JMX

Web view of the JMX branch in the historic svn repository (use "svn checkout svn://svn.code.sf.net/p/jikesrvm/svn/rvmroot/branches/RVM-127-JMX" to checkout the code)

threading, JNI

The JVM Tool interface is part of the Java Platform Debugger Architecture that JVMs can implement to provide debugging capabilities. We would like to have a full JMVTI implementation to allow debugging of Java applications that are running on Jikes RVM. Another benefit of JVMTI is that it allows low-level access to JVM internals. This can be used for instrumenting and monitoring the Jikes RVM using low-level code.

There is already a partial JMVTI implementation that was written by James Bornholt for GSoC 2011. His implementation should be used as a basis for this project.

Writeup of James Bornholt on the GSoC 2011 page

Web view of previous GSoC 2011 JVMTI work

infrastructure

The Jikes RVM project currently uses the Ruby-on-Rails application CatTrack to track test results. CatTrack is also responsible for sending regression mails.

This project would consist of upgrading CatTrack to use a more recent version of Ruby-on-Rails instead of the ancient Ruby-on-Rails 1.2.6. Potential candidates must have experience in Ruby-on-Rails to be able to take on this project: we don't have the necessary expertise to provide adequate mentoring to RoR beginners. The exact version numbers and the upgrade process need to be coordinated with our contacts at the Australian National University (where the servers are located). New features can be added to CatTrack after the upgrade is complete.

An alternative approach would be to get rid of CatTrack completely and move to a more general open-source solution. Note that this would be a much more disruptive change. A student proposal that suggests this approach must be very convincing to be considered. Another constraint for proposals of this kind is that we want to avoid using yet another language in our build infrastructure (see RVM-85 ). It might be acceptable to replace Ruby with another language but this must be discussed before such a proposal is submitted.

The X10 language project also uses CatTrack for their regression mails. Candidates should be prepared to coordinate with somebody from the X10 team to ensure that an upgraded version of CatTrack (or a replacement) is also a viable solution for them.

infrastructure, (additional subsystems as chosen by the student)

An infrastructure for unit tests and some initial unit tests were added to the Jikes RVM in GSoC 2012 by João Reys Santos. However, there is still a lot of work to do before we can consider the codebase to be reasonably well tested. We need more unit tests as well as more black-box tests.

Students should pick an area of interest (e.g. compilers, JNI, MMTk, classloading, threading, ...) and/or motivating use cases (e.g. get benchmark X or application Y running on Jikes RVM), identify and fix the corresponding problems and introduce adequate (unit) tests.

Note that extra effort will be required if students want to use mocking. Mockito does not work with GNU Classpath-based JVMs and our OpenJDK-port is not yet ready.

book: Michael Feathers, Working effectively with legacy code, Pearson Education, 2004

book: Andreas Zeller, Why programs fail: A guide to systematic debugging, Morgan Kaufmann, 2009

classloading, compilers

Jikes RVM currently does not implement a bytecode verifier. We would like to have a bytecode verifier that can verify classfiles at least up until Java 6 (we don't support Java 7 yet). The verifier needs to work with the baseline compiler as well as the optimizing compiler. Ideally, it should be possible to use the verifier from the command line without actually running the bytecode that is supposed to be checked. This could be done in a similar way to the OptTestHarness which enables users to control the compilers.

The verifier should be designed to support custom verification constraints. Some examples for possible constraints are listed in the JIRA issue linked below.

JIRA issue for the bytecode verifier

Jasmin assembler (useful for creating test cases that trigger verifier errors)

Chapter 4 of the JVM Specification

Java, reading papers and specifications, implementing algorithms from specifications and papers

MMTk

The GCspy framework for garbage collector visualization has become out-of-date and needs improving [RVM-388]. GCSpy 2.0 should update the framework to work properly with the latest version of Jikes RVM. In particular, it should support discontiguous spaces and provide drivers for more of MMTk's GC algorithms. In addition, the rewrite might improve modularity, and possibly integrate with the Eclipse Rich Client Platform.

GCspy: an adaptable heap visualisation framework

Java, C++, willingness to deal with low-level details, some understanding of garbage collection

MMTk

A Stop-The-World variant of the Compressor garbage collector was implemented for Jikes RVM in  GSoC 2010 by Michael Gendelman. The goal of this project is to improve the stability of Michael Gendelman's implementation so that it can be merged to mainline. Performance tuning may also be needed.

Students that are interested in this project should be familiar with garbage collection and MMTk.

Hint for very ambitious students: You can work on more complex variants of the Compressor (e.g. a concurrent version) once the the Stop-The-World variant has been merged and the project has determined that its quality is suitable.

paper: Haim Kermanya and Erez Petrank, The Compressor: concurrent, incremental, and parallel compaction (ACM link)

JIRA issue for the compressor (includes a link to the paper)

Michael Gendelman's work on the Compressor (includes a design document on the wiki)

Java, willingness to deal with low-level details, familiarity with garbage collection

compilers

Jikes RVM currently supports 32-bit Intel, and 32- and 64-bit Power PC architectures. This project involves porting Jikes RVM (initially the baseline compiler) to the 32-bit ARM architecture. Ambitious students could consider the optimizing compiler too, as a second step. Lots of preparatory work has been done in this area. I had an undergraduate student project at Glasgow University this year. He has done excellent refactoring work and we should be able to build on this to get a fully functional baseline compiler.

When my student's project is marked, I will put a PDF document up here. In the mean time, here is an out of date thesis about an earlier porting effort to ARM.

Java, willingness to deal with low-level details, familiarity with ARM instruction set

compilers

A Quick Compiler that does simple optimization and some use of registers, possibly modeled after existing dynamic code generation systems such as that of QEMU or valgrind. The point of such a compiler is to exploit "low hanging fruit". Previous work (10 years ago) took a somewhat different approach, but suggested that a compiler that applied a simple approach to register allocation and some simple optimizations reduced total execution over the current Baseline or Baseline+Opt compilation systems.

QEMU and valgrind are good starting points for developing the compilation / optimization strategy.

compiler expertise (analyses and optimizations)

infrastructure

Jikes RVM has lots of command-line flags, as you can see from the command line help. Researchers add new flags all the time, when they are working on experimental features. The current techniques for adding new flags, parsing flags, etc is quite complex. This project is about refactoring the code to make command line flag handling more straightforward. Possibilities (negotiable) include autocomplete for flags, suggestions for unrecognised flags, etc.

Maybe look at Google commandline flags library, and at bash completion for some ideas.

Java