Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

The mentoring organization application deadline for the Google Summer of Code 2011 is March 11. We have had some really excellent contributions to JikesRVM come out of previous Summers of Code, and we intend to apply again. For this we need a strong set of proposals, so please take the time to look at the ones below and offer some more.

FAQs etc

Timeline

Student application template

Previous years

Proposals

The projects are organised into the major components of Jikes RVM that they effect: Infrastructure, Garbage Collector (MMTk), Compilers and the Runtime System. We also have other projects that relate to Jikes RVM.

Jikes RVM infrastructure proposals

Enable Jikes RVM to use OpenJDK class libraries

We believe the largest limitation in the set of programs that can be run on Jikes RVM is that Jikes RVM primarily relies on the GNU Classpath class libraries. The most viable library plan for Jikes RVM is to switch to using Open JDK libraries. The work in switching is primarily in the VM/library interface and in the "core" classes in java.lang. This project for be of significant value to the research community because it will widen the set of benchmarks that can be used for Jikes RVM research.

Interested mentors: Daniel Frampton

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

Garbage Collector (MMTk) proposals

Concurrent Garbage Collectors

MMTk has a basic concurrent garbage collector and Laurence Hellyer added Sapphire as part of GSoC 2010. However, we would like to have more, for example, Concurrent immix, the Doliguez-Leroy-Gonthier algorithm (POPL93, POPL94, ISMM00), Azatchi et al (OOPSLA03), or mostly concurrent (Boehm91, Barabash et al 2005).

Interested mentors: Tony Hosking, Erez Petrank, Daniel Frampton

Generational Collector Organisation

Currently, the generational collectors in Jikes RVM use en masse promotion, i.e. all surviving objects in the nursery are promoted to the mature generation. Other VMs have adopted more complex generational organisations that require objects to survive more nursery collections before they are promoted. For example, HotSpot divides the young generation into an Eden (where objects are created) and Survivor semispaces. Implementations for functional languages have typically organised generations into steps. This project would implement some of these organisations.

Interested mentors: Richard Jones

Garbage Collection Visualisation

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

Interested mentors: Richard Jones

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, Daniel Frampton

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, Daniel Frampton

Separate Heap For VM objects

In most JVMs there is no confusion between memory allocated for the application and memory allocated by the running of the VM itself (for example a call to malloc() within the JIT). However, in Jikes RVM, the VM and the application are both written in Java. Moreover, they currently share the same heap. It would be very desirable to improve this situation and separately allocate VM and application objects. Aside from cleaner accounting and behaving more like a production JVM, there may be opportunities for performance optimizations since the lifetimes of objects created by the JIT will typically be bounded by the invocation of a single compilation, as an example.

This project would start by identifying all transitions from the application into the VM proper and channeling all such transitions through a zero-cost "trap", which simply serves as a marker. The trap can be viewed as analogous to a kernel trap in the OS setting. The project would also involve writing a simple checking routine which would walk the stack and determine whether execution was currently within the VM or application context. The combination of these mechanisms could then be used to identify and verify all application<->VM transitions.

Interested mentors: Andreas Sewe

Compiler proposals

Multi-core parallel compilation services

This project would add support to Jikes RVM runtime compilation to enable parallel compilation of methods in two different modes. Mode 1 (as at present) - individual methods are compiled sequentially in a single thread. Multiple methods could be compiled in parallel in separate threads. Mode 2 (new feature) - an individual method could be compiled using parallel data flow analysis in multiple threads. This would benefit compilation for large methods. There is an interesting research project in working out the trade-off between these two modes of parallel compilation. The GSoC project would involve generating the infrastructure to carry out this research project.

Interested mentors: Jeremy Singer

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.

Interested mentors: Tony Hosking

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

GIST

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.

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, Richard Jones, Daniel Frampton

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, Daniel Frampton

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, Daniel Frampton

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

  • No labels