New Garbage Collection Implementations for MMTk

We would be interested in hearing about adding new GC implementations to MMTk. Our highest priorities are on-the-fly garbage collectors (RVM-400), the Compressor(RVM-401), and a classic Baker collector(RVM-403).

Implementing and debugging a garbage collector is difficult, if you apply for a GC implementation project please explain your knowledge of the collector in question and your experience at implementing garbage collectors.

Interested mentors: Steve Blackburn

Garbage Collection Visualization

Progress has been made on this project since 2008 and we should update the project proposal accordingly. How can it build on last year's work? What about the tuning fork framework?

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.

RVM-399

Interested mentors: Steve Blackburn

Optimizing Compiler Restructure

We need to improve the compiler driver. Currently things are hard to understand and the compiler is very brittle.

x86 64 compiler support

Jikes RVM support code generation for 64bit Intel CPUs, but bugs remain in garbage collection and implementation of the optimizing compiler hasn't yet been undertaken. This project will complete 64bit support.

Interested mentors: Ian Rogers

Reduce cost of inlining runtime services

This project will look to reduce the cost of optimizing services repeatedly within the optimizing compiler. 

RVM-148

Interested mentors: Ian Rogers

Loop unrolling

Implement a better loop unrolling phase taking into account various considerations about when and how to unroll.

RVM-404 

Interested mentors: Ian Rogers

Copy eliminating baseline compiler

Work on this has been undertaken so we should update/remove this proposal.

strictfp support

This project will look to extend existing compilers to have strictfp support to enable the execution of strict math code. 

RVM-235

Interested mentors: Ian Rogers

Embedded Jikes RVM

Support for architectures like ARM.

Class Unloading

Currently all classes share a "Java table-of-contents" or the JTOC which has no support for unloading classes. We need to restructure the JTOC interface to support class unloading by making it per class loader, or per class. This is likely to also involve looking into modifying the current calling conventions.

RVM-324

Interested mentors: Robin Garner, Ian Rogers

Lock Reservation/Biasing

Lock reservation and biasing are ways of giving threads ownership of objects so that they can avoid or use cheaper tests to confirm their ownership of an object. Handling contention and releasing ownership of the objects is complicated. This project will look to implement these schemes in the RVM.

RVM-290 

Interested mentors: Tony Hosking, Ian Rogers

Java Native Access

Implement a cleaner, more code in Java, native syscall interface that wraps libraries like JNA does. Move C code into Jikes RVM.

Flexible Threading

Update this proposal to fix the thread model and reintroduce a greenthread mode of execution.

JVMTI implementation

Implement JVMTI to interface C debuggers and tools with Jikes RVM.

Harmony class library integration

The Apache Harmony project provides open source class libraries and virtual machines that are aiming to be certified as Java compatible. The Harmony libraries are already used by a number of products, such as Google's Android, and have been integrated into Jikes RVM. This project will continue this integration to solve problematic areas such as integration of the runtime system with Harmony.

RVM-358

Harmony-VM-2

Interested mentors: Ian Rogers, Tim Ellison

OpenJDK class library integration

Continued integration?

Modularity

Currently there is a connection between different parts of the RVM that is less than desirable. For example, the on-stack-replacement algorithm is implemented in parts in the class loader. We would like to have better isolation of components to more easily allow plug in replacements to be created. Such changes are likely to have an effect across the code base, so interacting with the development community will be important.

RVM-405

Interested mentors: Ian Rogers

Work on the continued integration of the RVM with JNODE

This project will look to continue to harmonize development effort of the Jikes RVM with the JNode operating system. 

RVM-382

Interested mentors: Ian Rogers, Peter Barth, Fabien Duminy

Jikes RVM for new languages

JSR-292 support in Jikes RVM.. Untyped languages such as Jikes RVM for JavaScript

PearColator

Development of PearColator as a Jikes RVM SoC project.