Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of senakafdo@gmail.com
 designates 209.85.142.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=IemOaVRo3nVXPNwdfys1Kj68gEss3bnuSHiXXTUp5Z36g+1eBWAQC8M5907PFe8fgHEKBGtCFKaSm6lSZ2O3W5fKNBYAWu1vKINti6eIto51ClPWyRVM8zngzKUYHjFSddYzwXOFwpcgWiRavfUDdwF733MTUBEfCl/50lYhrcs=
Message-ID: <8812c4670803300437u32803717gf5ce5ccac03cd781@mail.gmail.com>
Date: Sun, 30 Mar 2008 17:07:10 +0530
From: "Senaka Fernando" <senakafdo@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [GSOC2008] project proposal for harmony-gc-5
In-Reply-To: <c30d70960803300305h4e480b16q379f95afacb1bb81@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <8812c4670803291429q7f879399rc9e63f7ff8834de@mail.gmail.com>
	 <c30d70960803300305h4e480b16q379f95afacb1bb81@mail.gmail.com>

Hi Alexei,

Many thanks for Reviewing my proposal.

On 3/30/08, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> Hello Senaka,
>
> Good job. Let me share few ideas how to improve it.
>
> 1.
> > 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.

Regarding submitting code to Google, it was somewhat appearing in
their program timeline, [1]. I will actually submit code to Apache at
the end of each Checkpoint/Milestone according to what you mentioned
here, through the JIRA. However, what I'm not sure is whether it is
mandatory to submit the code to Google, if not which can be dropped.

[1] http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline

>
> 2.
> 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.

I will change that to DRLVM.

>
> 3.
> > 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 will rephrase that.

>
> 4
> 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.

OK, in that case I should rewrite logic within the Harmony GC, and
directly plug it isn't it? But, I might require an extension on the
Parrot side which will be capable of reading the Harmony GC, because
this end is C++ and the other is C. I will have to experiment it and
see.

>
> 5.
> 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.

OK.

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

OK.

>
> 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,
> Alexei
>