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=b7GbzyehGhpigLhF6fIL7+lr99plmpi728smYHWJ3sOfqvtrtrvGq9IiSDbUFElZSWPxFvTyLq+9hnTLf0/mfzjSx0JaRdfBBZYHeFFJ5VnkQz2GU0xeOWII9kvNZWVeg64fGN5WeKRPYjexlUJ7z7gRoYiJxxPdfDPU2u9QNZA=
Message-ID: <8812c4670803301046v460b4068x2a47ab6d06c8954b@mail.gmail.com>
Date: Sun, 30 Mar 2008 23:16:59 +0530
From: "Senaka Fernando" <senakafdo@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [GSOC2008] project proposal for harmony-gc-5
In-Reply-To: <c30d70960803301030p28844dfbg7dd6c5f31c5ccce7@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>
	 <8812c4670803300437u32803717gf5ce5ccac03cd781@mail.gmail.com>
	 <c30d70960803300454p1bd2d401x2c3f066c47963868@mail.gmail.com>
	 <8812c4670803300947q20e05b13v51a3cf3bb379bda4@mail.gmail.com>
	 <c30d70960803301030p28844dfbg7dd6c5f31c5ccce7@mail.gmail.com>

Thanks,

Regards,
Senaka

On 3/30/08, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> Senaka,
> To my perception the description is good. It would be great to get
> Xiao Feng feedback as well.
>
> Thanks.
>
> On Sun, Mar 30, 2008 at 8:47 PM, Senaka Fernando <senakafdo@gmail.com>
> wrote:
> > Hi all,
> >
> > I have incorporated modifications suggested by Alexei to my proposal.
> > Please be kind enough to read it and let me know whether there is
> > anything that needs further modification. Your feedback is greatly
> > appreciated. My proposal is available at [1]
> >
> >
> > [1] http://wiki.apache.org/general/SenakaFernando/GSoC2008/harmony-gc-5
> >
> > Regards,
> > Senaka
> >
> >
> >
> > On 3/30/08, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> > > Yes, you are correct about Google's code requirement. I've noticed
> > > their code requirement later. Ok, let me rephrase my suggestion in a
> > > more general and non-restricting way: be closer to the particular
> > > project, and do not pay to much attention for Google time line and
> > > other non-specific things. This does not mean "remove that from your
> > > proposal", but rather "add something project-specific into it".
> > > "Submit selected patches as JIRA references to Google as required"
> > > would be better. Just think of people from Apache who would be your
> > > readers.
> > >
> > > > OK, in that case I should rewrite logic within the Harmony GC
> > > You will have to patch both sides, but patches on Parrot side would be
> > > pretty limited: they have GC interface layer. Adjusting our GC to
> > > their interface layer would be more than writing a wrapper. Yes, it is
> > > something about changing logic.
> > >
> > >
> > >
> > > On Sun, Mar 30, 2008 at 2:37 PM, Senaka Fernando <senakafdo@gmail.com>
> > > wrote:
> > > > 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
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > With best regards,
> > > Alexei
> > >
> >
>
>
>
> --
> With best regards,
> Alexei
>