Google Summer Of Code 2008 Projects Proposals
1. Implement the "Compressor" GC proposed by Kermany and Petrank.
The Compressor garbage collector  is a compacting GC that leverages virtual memory support in underlying OS.
It compacts the heap in two passes.
 Haim Kermany, Erez Petrank: The Compressor: concurrent, incremental, and parallel compaction. PLDI 2006.
2. Implement the "Mapping Collector" proposed by Wegiel and Krintz.
The Mapping Collector  utilizes the virtual memory support in a novel way so that it can compact the heap
without moving the objects or fixing the references.
 Michal Wegiel and Chandra Krintz, The Mapping Collector: Virtual Memory Support for Generational, Parallel,
and Concurrent Compaction, ASPLOS 2008.
3. Write a graphic font-end for Harmony memory management.
Harmony runtime needs a graphic front-end visualizing the memory management activities and the runtime status.
It can be standalone or better an Eclipse plugin. It can be online display of the runtime execution, or offline
processing of the log.
4. Unify the native memory management of Harmony DRLVM.
DRLVM uses inconsistent APIs for native memory management, such as APR or malloc or mmap. It is desirable
to have a unified API for native memory management. Hopefully the runtime native memory usage can be
managed with a global view and then optimized. This layer could be extended to provide the API for Java heap
native management as well.
5. Implement "Bundle Tool", a tool to make binary snapshots of java applications with Harmony.
There is no simple way for Harmony users to define the list of needed classes, jars and native libraries for their
applications. Create a tool that creates a Harmony package with the classes and native libraries used by
specific application or work flow. First of all this application should collect data from one or multiple application
runs and then create a Harmony bundle without unneeded classes and native code.
6. Refactor Java Bytecode Translator in Harmony JIT.
Interaction between ByteCodeParser, JavaLabelPrepass, JavaByteCodeTranslator classes is very complicated and
error-prone. Refactor Java bytecode translator in the Jitrino.OPT to make the code cleaner and simplify the data
structures used. C++ skills required.
7. Support dynamic languages, support invokedynamic bytecode instruction in VM and JIT.
Support the invokedynamic
instruction i.e. the ideas of JSR 292
draft. And implement basic support for a
We want this language to have dynamic typing, reasonable user base, usable standard library, a set of
8. Make FreeCol game playable on Harmony
For someone who is interested in a graphical user interface development, enabling one of the most popular
strategic games may be an interesting task. Since client API development is not finished, the one who would
choose this task might learn designing of areas related to image processing, code development, bug fixing
and refactoring. See for details
on the current status of the project. BTW, you may want to replace FreeCol
enabling with enabling of your favorite application, and this is welcome.
9. Build a garbage collector for C/C++ programs on the top of Harmony.
One may notice a lack of open source effective parallel GC implementation for C/C++ programs. For example,
Parrot (Perl 6) community expressed an interest
in attaching our GC to their code base. If numbers would
show some benefit, we might get another customer for our code base. Successful completion of GC library on
the top of Harmony would teach a person in refactoring skills and give a good background in garbage collection.
10. Implement one of the JDK's command line tools.
Harmony is missing several of the tools that ship with the JDK, including jar, jconsole, javaws and policytool.
For this task you would implement one of these tools, either in Java or C/C++ if preferred.
11. Integrate Harmony and Jikes RVM.
is a research virtual machine that has been a test bed for many JVM and GC developments.
This project will look to integrate the harmony libraries with Jikes RVM. This will require work on the VM
interfaces (the Jikes RVM is a Java-in-Java VM meaning that current VM interfaces are written in Java rather
than native code) as well as exploring how Jikes RVM can be integrated with Harmony's threading and other