Great to hear that! I'll go take a look and fix any grammar/nice formatting in a while.
Thank you, Nadya Morozova -----Original Message----- From: Alexey Varlamov [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 1:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] more self-dependent VM tasks, newbies welcome Nadya, Thanks for the links, I added new subpage to TODO_List_for_DRLVM. 2006/11/2, Morozova, Nadezhda <[EMAIL PROTECTED]>: > Alexey, > Do you think you can post these on Wiki? We actually have several pages > there that can help arrange and store such development items: > Starting point, choose your subpage > http://wiki.apache.org/harmony/TODO_List_for_DRLVM > Sample http://wiki.apache.org/harmony/JIT_Development_Tasks > Wiki seems easier to find and use than an email thread on the list. What > do you say? > Do you need my help with this? > > Thank you, > Nadya Morozova > > > -----Original Message----- > From: Alexey Varlamov [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 02, 2006 9:24 AM > To: harmony-dev > Subject: [drlvm] more self-dependent VM tasks, newbies welcome > > 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\inte > rnal\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? >
