Google Summer of Code 2008 - Project Proposal


Senaka L. Fernando


senakafdo AT gmail DOT com

Senaka DOT Fernando AT cse DOT mrt DOT ac DOT lk


senakafdo AT gmail DOT com

Project ID


Project Summary

Build a garbage collector for C/C++ programs on the top of Harmony


Apache Harmony is an Open Source Implementation of the Java5 SE. With the allowance of Open Source implementations of the JSR, Apache Harmony began as a project to become a Apache 2.0 Licensed alternative to Java from Sun Microsystems. Most of Harmony is functional, and can already be used in place of Java. But, however, improvements are yet to happen.

Harmony relies on its user-base as means of contribution through patches, financial support, evaluations, and sensible use-cases. Thus, contribution and active involvement of users within the scope of Harmony is always encouraged. As a result of this several communities have shown interest in this project. The Parrot VM project from Perl, 1], is one such party interested in plugging the Harmony Garbage Collector into their VM, 2], and as a whole improving the visibility and the usefulness of the Apache Harmony Project.

The project harmony-gc-5, 3], or, "Build a garbage collector for C/C++ programs on the top of Harmony", is aimed at porting the Harmony gc into C/C++ applications. In order to get started, we will be looking into Parrot. The broader aim is to make it possible for any project hoping to adopt the Harmony gc, make use of it, once this project has been completed. Initial effort has been carried out, but, have resulted in issues in linking, as well as conflicts in the porting layer.

My role in this project will result in resolution of such issues and a better, and efficient implementation that would make the Open Source Parallel Garbage Collector of Apache Harmony pluggable to Parrot, and as a whole to any other C/C++ application.




Project Detail

The Harmony VM, 1], consists of several key elements, such as the Core, Garbage Collector, JIT Compiler, Interpreter, Thread Manager, Execution Manager and a porting layer. The Garbage collector used by the present implementation, 2], known as GCv5 of Apache Harmony, is a fully parallel Garbage Collector that can operate in both Generational and Non-Generational modes. This can be used on Shared Memory systems operating in multi-processor and multi-core environments. It contains support for thread safe compacting, and copying, as well as mark-sweep collection algorithms.

One major feature of Harmony's GC, is that it has been designed as a pluggable component rather than a embedded implementation within the Harmony VM. Thus, the Garbage Collector rather exposes an interface to the VM. This makes it possible for other implementations such as Parrot, invoke the GC through a customized interface. I will be getting the GC to work with Parrot, so that we can be certain that it can be used by any other C/C++ application. My task in this project will be developing such an interface between The Harmony GCv5 and the Parrot VM, whilst resolving many blocking issues as linker errors and porting layer conflicts.

Parrot, has the ability to optionally accept another Garbage Collector during configuration. And, this would require a GC interface that can be recognized by Parrot. I will be developing the necessary porting layer that will on one side talk to parrot and on the other talk to the Harmony GC. The major challenge will be the aligning of the interfaces of Parrot and Harmony so that interaction would be possible, whilst unleashing the proper parallelism entrusted by the Harmony GC. As, I don't have much control over the Parrot side which has a fixed interface to a pluggable GC, I will have to mostly rely on shaping the interface exposed by Harmony, with necessary modifications so that it could communicate with Parrot. This will most essentially involve inventing new interfacing points within the Harmony GC, that confirms to the expectations of Parrot.

My approach to this project targets several issues,

  1. Creating an interface within Harmony making it pluggable to Parrot
  2. Resolving compilation and run-time issues, that would result once Parrot starts using the Harmony GC
  3. Improving the present GC, based on experiences with Parrot
  4. And Finally creating a solid Garbage collector that could be plugged in to Parrot, which runs on top of Harmony

The porting layer would expose a C interface to the Parrot side that will communicate with the Parrot VM. On the other side, it will be utilizing the C++ Harmony GC in its implementation logic. My approach will include a C++ dll, built using the Harmony build system which exposes a C interface that confirms to the expectation of Parrot. I will be working closely with both the Apache Harmony, and Parrot (Perl) communities, so that I could address porting issues that arise when combining the two systems. Another important aspect that I will be addressing is the cross platform usability of the porting layer, making it rather independent of the underlying operating system. This also will make Harmony GC pluggable to any other C/C++ project.

The final outcome should pass all the stress tests from Parrot on its GC, as well as other tests in the Parrot test suite.




  1. Architectural design on how Harmony GC connects to Parrot VM.
  2. GC fully independent of the Java Sources and VM core.
  3. Porting layer capable of connecting the Harmony GC written in C++ to the Parrot VM written in C.
  4. Resolving issues blocking the porting of the GC through the exposed interface.
  5. Improvements and enhancements to the current GC.
  6. Documentation explaining how the Harmony GC can be plugged into another VM.
  7. Alternative GC to Parrot VM.

Project Timeline

April 15 - April 30: Understanding the Harmony GC as well as Parrot, and a critical survey into the implementation

May 1 - May 15: Developing a initial design of the architecture of the porting layer

May 16 - May 24: Evaluation of the design of the architecture of the porting layer (with the participation of both communities)

May 25: [Milestone 1] Initial Architectural design of porting layer of Harmony GC to Parrot VM (subjected to change as the project progresses)

May 25: Issue regarding the improvement to the Harmony GC raised on Harmony JIRA

May 26: Coding of project begins

May 26 - June 2: Make it possible to Build Harmony GC without Java Sources and VM Core

June 3: [Milestone 2] Initial Version of Harmony GC, independent of Java Source and VM Core [GCv5_Parrot-M2]

June 3: First patch submitted to Harmony JIRA

June 4 - June 10: Add another GC to Parrot with Calls redirected to Loaded Library and Understanding Parrot GC Interface

June 11 - June 17: Implement Parrot Specific GC Calls (ex:- basic interfaces such as Memory Allocation)

June 18: [Checkpoint 1] Small applications which do not need much heap should start to work right now

June 18: [Milestone 3] Porting Layer capable of connecting Harmony to Parrot [GCv5_Parrot-M3]

June 19 - June 23: Building of simple logger/debugger infrastructure

June 24 - June 29: Stack Enumeration

June 30 - July 4: PMC Object Layout

July 5 - July 6: [Checkpoint 2] Get the first GC passed

July 7: [Milestone 4] Harmony GC pluggable to Parrot VM with basic functionality [GCv5_Parrot-M4]

June 7: Second patch submitted to Harmony JIRA

July 8 - July 14: Preparation and submission of Mid-Term evaluation

July 15 - July 28: Finalization with support for weak references

July 28 - July 31: [Checkpoint 3] Parrot can now run with the Harmony GC

August 1: [Milestone 5] Enhanced Harmony GC with fully Parrot compatibility [GCv5_Parrot-M5]

August 1 - August 7: Documentation of Project

August 7 - August 11: Publishing and Testing of Harmony GC for Parrot

August 11: [Milestone 6] Harmony GC as an alternative GC to Parrot VM pre-release version [GCv5_Parrot-M6]

August 11: Third patch submitted to Harmony JIRA

August 12 - August 17: Preparation for Final Evaluation while fixing any issues reported on the JIRA Issue Tracker

August 18: [Milestone 7] Harmony GC as an alternative GC to Parrot VM final version [GCv5_Parrot]

August 18: Fourth patch submitted to Harmony JIRA

August 18: Development ends

August 19 - September 1: submission of Final evaluation

September 3: Submitting approved patches on JIRA as references to Google as required

Community Involvement

The project, Harmony-gc-5, will involve a participation in both Apache Harmony, as well as the Perl-Parrot communities. I have already started discussions on this project in the developer mailing lists of both Apache Harmony (dev AT harmony DOT apache DOT org) and Parrot (parrot-porters AT perl DOT org), and also have contacted persons who initiated the effort in connecting the Harmony GC to Parrot. I have received positive feedback and support from both communities, who are interested in supporting this project. I'm certain that I will continue to receive support and feedback throughout the duration of this project.

Initial Research

I have done initial research in order to attain a background understanding on the project as requested on the Harmony developer list. One such research is the comparison of the Harmony and Parrot VM <=> GC interfaces, which can be found at 1]. At present, I'm working on further understanding the Parrot's GC, and also have patched some bugs on both Harmony and Parrot.



I'm a student at the Department of Computer Science and Engineering at the University of Moratuwa, Sri Lanka. I'm at present reading for my Bachelors in Engineering. I have completed three years at the university, and will be starting the fourth in May 2008. I have over 4 years of experience in C/C++ projects. I'm also familiar with other programming languages such as C#, and Java.

I recently completed my internship at WSO2 Incorporated. My major involvements during the internship was creating a C++ wrapper to WSO2 Web Services Framework for C (code: WSF/C), known as WSO2 Web Services Framework for C++ (code: WSF/C++), 1]. Through this project I have gained hands on experience in developing software applications involved with communication between C and C++ dynamic link libraries.

I'm also familiar with Apache HTTP, Apache APR, and Web Services projects at the Apache Software Foundation.



My involvement with Harmony is motivated by an interest in developing real world applications that would benefit broader audiences, as well as understanding newer concepts in the software industry. I'm also looking forward in improving my visibility within the Open Source community through openings such as the Google Summer of Code. I have been a user of many open source technologies of which I have largely benefited. But, until very recently I have not been a developer active in the open source community.

My interest in become an active contributor to open source as well as learning technologies such as Garbage Collection is the prime motivation of participating in the Google Summer of Code 2008, taking the project, Harmony-gc-5.

SenakaFernando/GSoC2008/harmony-gc-5 (last edited 2009-09-20 23:35:10 by localhost)