harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm] more self-dependent VM tasks, newbies welcome
Date Fri, 03 Nov 2006 08:28:15 GMT
On the 0x216 day of Apache Harmony Geir Magnusson, Jr. wrote:
> Sure, so use wiki as a community collaboration tool, and then point to
> the JIRAs...

OK, my suggestion was to put links to JIRA tasks from the page:
http://wiki.apache.org/harmony/DRLVM%20newbie%20tasks

Now I think you all agree. So I did it.

> geir
> 
> Rana Dasgupta wrote:
> >     They serve different purposes. The Wiki is just a broad reminder
> > to even a visitor to Harmony of what remains to be done. I think
> > that the JIRA is more specific, maybe even more technical. The TODO
> > page as it is today, with sublinks, also seems well suited to
> > capture this info. But it's not a big deal.
> >  On 11/2/06, *Geir Magnusson Jr.* <geir@pobox.com
> > <mailto:geir@pobox.com>> wrote:
> >     Rana Dasgupta wrote:
> >      > No problem with them being both on the Wiki and the JIRA, I think.
> >     Other than getting out of sync....  it just makes sense to use
> > the
> >     "issue tracking system" for... "issue tracking" :)
> >     geir
> >      >
> >      > On 02 Nov 2006 17:57:29 +0600, Egor Pasko < egor.pasko@gmail.com
> >     <mailto:egor.pasko@gmail.com>> wrote:
> >      >>
> >      >> On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote:
> >      >> > Alexey Varlamov wrote:
> >      >> > > 2006/11/2, Geir Magnusson Jr. < geir@pobox.com
> >     <mailto: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
> >      >>
> >      >>
> >      >
> >
> 

-- 
Egor Pasko


Mime
View raw message