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 17:30:17 GMT
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

Mime
View raw message