You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexey Varlamov <al...@gmail.com> on 2006/11/02 07:24:01 UTC
[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\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?
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Salikh Zakirov wrote:
> Geir Magnusson Jr. wrote:
>> Only further thought - how do I get to this page? Maybe I'm not seeing
>> it. From front page, there is the "TODO list" for DRLVM, but there's no
>> link to the 'newbie" page.
>
> that's not a problem, as long as the newbie page is clickable-through
> from a starting page.
>
> I expect that any newbie seriously considering contributing to the project
> will read all available sources thoroughly before jumping in.
>
> That's why I suggest *not* to add "newbie" page to the wiki front page,
> as it tends to get cluttered too quickly.
> Let's keep the Front Page clean and logical (and thus short).
Ah. I wasn't advocating putting it on the front page, but putting it on
a comprehensive 'todo' list on DRLVM, maybe grouped by difficulty.
geir
>
>
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by Salikh Zakirov <Sa...@Intel.com>.
Geir Magnusson Jr. wrote:
> Only further thought - how do I get to this page? Maybe I'm not seeing
> it. From front page, there is the "TODO list" for DRLVM, but there's no
> link to the 'newbie" page.
that's not a problem, as long as the newbie page is clickable-through
from a starting page.
I expect that any newbie seriously considering contributing to the project
will read all available sources thoroughly before jumping in.
That's why I suggest *not* to add "newbie" page to the wiki front page,
as it tends to get cluttered too quickly.
Let's keep the Front Page clean and logical (and thus short).
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x216 day of Apache Harmony Geir Magnusson, Jr. wrote:
> Egor Pasko wrote:
> > 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.
>
> :)
>
> Only further thought - how do I get to this page? Maybe I'm not
> seeing it. From front page, there is the "TODO list" for DRLVM, but
> there's no link to the 'newbie" page.
eee..
FrontPage -> TODO List For DRLVM -> Improve kernel classes/natives code sharing
I was more lucky :)
> Also, maybe organize these "newbie" tasks with the other tasks, but
> mark them as "easy" or such?
maybe. "JIT Development Tasks" are organized in this way. Or just
change how the link reads?
> geir
>
> >
> >> 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
> >>> <ma...@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
> >>> <ma...@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
> >>> <ma...@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
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Egor Pasko wrote:
> 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.
:)
Only further thought - how do I get to this page? Maybe I'm not seeing
it. From front page, there is the "TODO list" for DRLVM, but there's no
link to the 'newbie" page.
Also, maybe organize these "newbie" tasks with the other tasks, but mark
them as "easy" or such?
geir
>
>> 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
>>> <ma...@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
>>> <ma...@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
>>> <ma...@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
>>> >>
>>> >>
>>> >
>>>
>
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by Alexey Varlamov <al...@gmail.com>.
Egor, thanks for doing this.
03 Nov 2006 14:28:15 +0600, Egor Pasko <eg...@gmail.com>:
> 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.
>
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by Egor Pasko <eg...@gmail.com>.
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
> > <ma...@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
> > <ma...@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
> > <ma...@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
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Sure, so use wiki as a community collaboration tool, and then point to
the JIRAs...
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
> <ma...@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
> <ma...@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
> <ma...@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
> >>
> >>
> >
>
>
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by Alexey Petrenko <al...@gmail.com>.
I agree with Rana here.
And another thing... There are people who are more interested in
"develop smth" then "fix smth". And to catch such kind of peolpe TODO
list in WIKI is much better then JIRA.
Just IMHO :)
SY, Alexey
2006/11/2, Rana Dasgupta <rd...@gmail.com>:
> 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. <ge...@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 <eg...@gmail.com> wrote:
> > >>
> > >> On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote:
> > >> > Alexey Varlamov wrote:
> > >> > > 2006/11/2, Geir Magnusson Jr. <ge...@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
> > >>
> > >>
> > >
> >
>
>
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by Rana Dasgupta <rd...@gmail.com>.
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. <ge...@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 <eg...@gmail.com> wrote:
> >>
> >> On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote:
> >> > Alexey Varlamov wrote:
> >> > > 2006/11/2, Geir Magnusson Jr. <ge...@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
> >>
> >>
> >
>
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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 <eg...@gmail.com> wrote:
>>
>> On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote:
>> > Alexey Varlamov wrote:
>> > > 2006/11/2, Geir Magnusson Jr. <ge...@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
>>
>>
>
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by Rana Dasgupta <rd...@gmail.com>.
No problem with them being both on the Wiki and the JIRA, I think.
On 02 Nov 2006 17:57:29 +0600, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote:
> > Alexey Varlamov wrote:
> > > 2006/11/2, Geir Magnusson Jr. <ge...@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
>
>
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote:
> Alexey Varlamov wrote:
> > 2006/11/2, Geir Magnusson Jr. <ge...@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
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Alexey Varlamov wrote:
> 2006/11/2, Geir Magnusson Jr. <ge...@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...
>
>> 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?
>> >
>>
>
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by Alexey Varlamov <al...@gmail.com>.
2006/11/2, Geir Magnusson Jr. <ge...@pobox.com>:
> Put them in as JIRAs
Done: HARMONY-2051, 2052, 2053.
> 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?
> >
>
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Put them in as JIRAs
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?
>