harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [GSOC2008] project proposal for harmony-gc-5
Date Sun, 30 Mar 2008 10:05:57 GMT
Hello Senaka,

Good job. Let me share few ideas how to improve it.

> September 3: Submitting code and documentation to Google
The code should be submitted to Apache in patches attached to JIRA
issues with ASF license granted.

DRL is actually a former name of one of the Intel's labs. Better to
address a module you are describing as DRLVM or Harmony VM.

> As an asset to the improvement of Apache Harmony, several other communities have shown
interest in this project.
Word-to-word translation to Russian makes sense, but I never have seen
"asset" in this context. May be it worth rephrasing that. For Harmony
the more customers we have, the more successful we are since customers
of open source support us with patches, money, or just words of
gratitude and sensible use cases. May be this impact is about
strengthening Harmony community making an interest to Harmony deeper
to the stage of acceptance?

I do not believe that creating an efficient wrapper is possible. This
is particularly important to align with Xiao Feng due to his extensive
experience in GC architecture. My current perception is that you
should just branch Harmony gc and do all the staff to make Parrot work
hacking into GC code directly and not thinking of DRLVM. Finally, when
you get Parrot running, you will understand better the way of
maintaining a code base. You may either maintain a branch, or add a
number of #ifdef statements to the initial code.

This would be quite non-trivial to align interfaces, and thinking of
code base merge would a pretty trivial task compared to that.

Instead of generic terms such as "release", "patch release" I would
suggest problem-related work breakdown, eg

1. Get Harmony, build Harmony GC getting rid of java sources and vmcore
2. Add another GC to Parrot with calls redirected to loaded library,
understand Parrot GC interface
3. Implement parrot-specific GC interface calls
    basic interfaces such as memory allocation
        checkpoint: small applications which do not need much heap
should start to work right now
    build a simple logger or other debugging infrastructure
    stack enumeration
    PMC object layout
        checkpoint: get the first GC passed
    finalization and weak references
Align this plan on the time scale.

6. Rewrite deliverables in terms of checkpoints. I believe getting
things work even without finalization is pretty ambitious for three

Thank you for your effort.

On Sun, Mar 30, 2008 at 1:29 AM, Senaka Fernando <senakafdo@gmail.com> wrote:
> I have added the project proposal for harmony-gc-5 at [1]. I would be really
>  pleased if you could be kind enough to review it and suggest where I could
>  improve it.
>  [1] http://wiki.apache.org/general/SenakaFernando/GSoC2008/harmony-gc-5
>  Regards,
>  Senaka

With best regards,

View raw message