harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando" <senaka...@gmail.com>
Subject Re: [GSOC2008] project proposal for harmony-gc-5
Date Sun, 30 Mar 2008 16:47:35 GMT
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
>

Mime
View raw message