harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morozova, Nadezhda" <nadezhda.moroz...@intel.com>
Subject RE: [drlvm] more self-dependent VM tasks, newbies welcome
Date Thu, 02 Nov 2006 06:31:39 GMT
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:alexey.v.varlamov@gmail.com] 
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?

Mime
View raw message