Google Summer of Code 2013

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