Thanks, Regards, Senaka
On 3/30/08, Alexei Fedotov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > > wrote: > > > > Hi Alexei, > > > > > > > > Many thanks for Reviewing my proposal. > > > > > > > > > > > > On 3/30/08, Alexei Fedotov <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> > > > > > 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 >
