Ideas for code contributions

This page highlights some ideas for code contributions. Some of =
these selections also appear in our =
issue tracker. Please volunteer to pluck these fruit, or suggest high-p=
riority, but low-effort tasks by creating new tracker entries. If you want =
to help out and don't know what to do, ask us on the mailing lists and mention what kind of tasks you're in=
terested in.

Low-hanging fruit (high priority, low-effort)

Complete missing pieces of library interface: There ar=
e a handful of methods in Jikes RVM's implementation of a few core library =
classes (java.lang.Class, java.lang.Runtime, jav=
a.lang.Throwable) that throw VM_UnimplementedError. Provide an implemen=
tation for one of these methods.

Improve efficiency of some optimizing compiler phase: =
Many of the optimizing compiler passes use sub-optimal data structures, and=
compile-time could easily be improved. Some simple phases to start with in=
clude the local optimizations and flow-insensitive optimizations.

Strip mining: T=
his optimization would be profitable, by reducing the overhead of yield poi=
nt checks in tight loops.

Global Array Bounds Check Elimination=
: While the literature presents several algorithms fo=
r array bounds check elimination, the optimizing compiler does not have a c=
omplete implementation. Note that there are some non-trivial technical diff=
iculties with ABCD, regarding integer overf=
low. A simple range propagation dataflow solver would be an improvement ove=
r what the system has now (namely nothing).

High priority=
, large effort

Support for OpenJDK as a class library: We have received community contributions for OpenJDK support. However, th=
e patch set is large and not split into commits. Some parts of the patch se=
t probably need to be changed or rewritten. You can help by grouping change=
s into commits and testing those. Reviews would also be helpful.

Improve situation for the optimizing compiler so that we can en=
able previously disabled optimizations: Ther=
e are a number of optimizations in the opt compiler that are currently disa=
bled by default because they are considered too buggy. We currently don't h=
ave proper tests for the optimizing compilers so we need to write a lot of =
tests to ensure that the compiler works correctly. The compiler-internal IR=
verification (and its paranoid variant) could also be improved. There are =
also opportunities in the refactoring of the phase organi=
sation.

A number of other possible projects can be found on the Project proposal=
s / ideas pages that are linked from for our Google Summer of =
Code pages.