Garbage Collection

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.

Garbage Collection Visualization

the Jikes RVM has had GC visualization previously through the GCspy framework. This has become slightly out-of-date and it would be interesting to improve it and possibly look to integrate the visualization side of the work with a sister project of the RVM's tuning fork.

Implementing and debugging a garbage collector is difficult. This project is probably only suitable for someone with extensive implementation experience with either or both of MMTk and the algorithm in question.

Interested mentors: Steve Blackburn

Compilers

Copy eliminating baseline compiler

A new framework for baseline code generation using a copy eliminating baseline compiler.

Work on the continued integration of the RVM with JNODE

Runtime services

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.

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.

Native Threading

The Jikes RVM's threading model was refactored and made more modular last year. A native thread stub exists without any implementation. We should implement this stub for different underlying threading systems. Some of the underlying threading systems we'd hope to support are pthreads, Windows threads, glib threads and Harmony's hythreads.

Harmony class library support

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 and we would like to integrate them into the Jikes RVM.

OpenJDK class library support

The OpenJDK class libraries are the standard class libraries in use in Sun and other production VMs. They are now available under the GPL but with a native interface implemented typically in a file called jvm.cpp (see Cacao). We would like to integrate with OpenJDK and fix likely issues in wanting to have Java-in-Java implementations of a lot of their calls, as well as support for different threading models.

Debugger support

Following last years SoC we have partial JDWP support. It would be good to increase this to include things such as break points. It would also be good to implement the JVMTI native interface for debugging.

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.