Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: harmony-dev@incubator.apache.org
From: Egor Pasko <egor.pasko@gmail.com>
Subject: Re: [drlvm] more self-dependent VM tasks, newbies welcome
Date: 02 Nov 2006 17:57:29 +0600
Lines: 69
Message-ID: <ufyd283iu.fsf@gmail.com>
References: <f944d83d0611012224j5dd2a7b3u31451ca633a180e7@mail.gmail.com>
 <4549D404.9000504@pobox.com>
 <f944d83d0611020332s31933b08l78143f384a8eca77@mail.gmail.com>
 <4549D82D.7010505@pobox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Sender: news <news@sea.gmane.org>

On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote:
> Alexey Varlamov wrote:
> > 2006/11/2, Geir Magnusson Jr. <geir@pobox.com>:
> >> Put them in as JIRAs
> > Done: HARMONY-2051, 2052, 2053.
> 
> Thanks - that just makes it easy for people to grab them and get going...

maybe, put the list of JIRAs on wiki?

> >
> >> Alexey Varlamov wrote:
> >> > Below is a list of isolated development tasks which do not require
> >> > advanced knowledge of VM and could be a nice start for newbies to get
> >> > acquainted with the code. All items are targeted for better code
> >> > sharing.
> >> >
> >> > 1) Eliminate duplicate implementation of j.l.Runtime.Process in kernel
> >> > classes of DRLVM [1]. The classlib provides neat portlib-based
> >> > reference implementation [2], which should be reused. These 2 impls
> >> > are roughly identical, so one needs to made more scrupulous comparison
> >> > and squeeze some features/fixes of [1] which may be missing in [2],
> >> > then employ [2] in j.l.Runtime of DRLVM and drop [1].
> >> >
> >> > 2) Improve/re-implement a parser of generic signatures in DRLVM kernel
> >> > classes [3], and move this functionality to classlib (luni ?), so
> >> > other VMs could reuse it for 1.5 support. The current impl is somewhat
> >> > messy and half-baked, one need to invent more shaped and modular API
> >> > to the parser. One more possible issue is parser's dependency on
> >> > antlr, which may be considered overkill for this duty. I think antlr
> >> > has its pros, like more illustrative code with clear correlation to
> >> > formal grammar [4]; unfortunately this is not the case with the impl
> >> > in question. OTOH minimizing number of dependencies for VM is always
> >> > good.
> >> >
> >> > 3) Classlib's j.u.TimeZone expects "user.timezone" property value
> >> > initialized during VM startup (BTW I did not find explicit statement
> >> > in VMI docs for that, only indirect reference in kernel stub for
> >> > j.l.System). I believe this action should be done by hyluni natives
> >> > during JNI_OnLoad, no reason to burden VM with it. Therefore I suggest
> >> > to move "port_user_timezone()" function [5] from DRLVM to classlib
> >> > (luni/port), and fix DRLVM & hyluni accordingly.
> >> >
> >> > [1]
> >> working_vm\vm\vmcore\src\kernel_classes\javasrc\java\lang\Runtime.java
> >> > + working_vm\vm\vmcore\src\kernel_classes\native\Runtime_[lnx|win].cpp
> >> > [2]
> >> >
> >> working_classlib\modules\luni\src\main\java\org\apache\harmony\luni\internal\process\*
> >> >
> >> > + working_classlib\modules\luni\src\main\native\luni\shared\process.c
> >> > [3]
> >> >
> >> working_vm\vm\vmcore\src\kernel_classes\javasrc\org\apache\harmony\lang\reflect\**
> >> >
> >> > [4]
> >> >
> >> http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.pdf
> >> > Para 4.4.4
> >> > [5] working_vm\vm\port\src\misc\[win|linux]\timezone.c
> >> >
> >> > Comments? Should I put this somewhere on the Wiki?
> >> >
> >>
> >
> 

-- 
Egor Pasko, Intel Managed Runtime Division