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 11:54:20 GMT
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