harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] more self-dependent VM tasks, newbies welcome
Date Thu, 02 Nov 2006 14:56:32 GMT


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> wrote:
>>
>> 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
>>
>>
> 

Mime
View raw message