Thanks Steve!
Looking at these, they seem to be split between working at the
respective projects, and working here.
For stuff elsewhere, how do we want to keep in touch? Cross-posting
might be too much, but maybe people that do go work on these ideas
elsewhere can report back from time to time?
For the stuff that can work here, lets try to establish informal
subject keys (ex [dynaload] ........ ) so we can separate what is
what on the dev list. Also, I'll setup SVN and start the committer
policy discussion. We're going to need to highly segment the code
repository for reasons that will be made clear.
geir
On May 27, 2005, at 5:30 PM, Steve Blackburn wrote:
Hi all,
I imagine I'm not alone in thinking that there are a great many
concrete things people can be working on right away, even while
discussion on key design issues continues. It would be good to have a
work list of concrete work items that eager folks can go to. So I'll
stick my neck out and throw out a list of a few tasks that can be
worked on right away. These include prototyping, research and
improvements to existing infrastructure. I have not included broad
design issues on there since design issues are not "projects", but the
subject of large scale discusion.
Among the items listed below, I have included items from MMTk and
Jikes RVM and I'm hoping others will do the same and add items from
other projects that work towards the goal of contributing to the
Harmony project. I hope everyone feels free to add to the list with
any work items they can think of (and argue for the removal of items
if they want). This is just a start. The list definitely needs
improving and growing, but at least there is no reason for anyone to
be sitting on their hands ;-)
What do people think?
--Steve
. prototype backend generator [prototype]
Explore Ertl & Gregg's work to develop a "backend generator" which
leverages the portability of gcj to automatically generate backends
for a simple JIT. The semantics of Java bytecodes are expressed
using Java code, and then gcj is used to generate code fragments
which are then captured for use by a simple JIT (Ertl & Gregg used C
and gcc, but with vmmagic support, Java and gcj would be nicer).
See also
http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/
200505.mbox/[EMAIL PROTECTED]
. vmmagic support for gcj [gcj]
Implement the vmmagic unboxed types in gcj, so they are compiled to
unboxed native operations (eg Address.loadInt() will perform an
integer load from an address value, and all instances of Address
will appear not as object instances but as 32/64 bit primitives).
http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/package-
summary.html
This will allow gcj to be used to build Java code which uses the
vmmagic primitves. Thus gcj could be used to build a virtual
machine image, an interpreter, or be used to automatically generate
a compiler back end.
. bytecode optimization [reserach]
On architectures where there is no high performance JIT, the
performance of the interpreter or simple jit (see backend generator
project) will be the limiting factor. (High performance JITs are
heavyweight and inevitably will only exist on the architectures were
there has been demonstrated demand for it). Since a simple
interpreter or simple JIT has very limited opportunity for
optimization, it may be very important to perform bytecode
optimization. There are a number of toolkits including bloat and
soot.
http://www.sable.mcgill.ca/soot/
http://www.cs.purdue.edu/s3/projects/bloat/
http://portal.acm.org/citation.cfm?id=781995.782008
. dynamic loading VM components and libraries [research]
Whether built in Java, C/C++ or a mix, harmony should probably have
strong support for dynamic loading and sharing of precompiled
"libraries" designed in from the begining. This is a very
interesting problem space, possibly made more interesting by
JSR-121. Jikes RVM, for example, mmaps a monolithic image
corresponding to a lot of precompiled and initialized classes. ORP
dynamically loads components such as the JIT. Generalizing these
ideas would be enormously helpful to harmony. Minimizing the
footprint of the VM, particularly in the context of multiple VMs is
interesting. There are complex issues associated with class
initialization and related code optimization issues (a static final
field that is initiated in a context sensitive way can't be constant
folded by an optimizing compiler except in a context specific
way---in other words the optimization would have to be ignored or
else separate code would have to be generated for each instance).
This also stirs up questions of heap and memory layout, the location
of class fields versus code etc etc. There is a lot here. It is
very important and very interesting. As far as jsr 121 goes, it is
important to note that Doug Lea is involved in both Harmony and the
JSR proposal.
http://jcp.org/aboutJava/communityprocess/pr/jsr121/index.html
. benchmarks [dacapo]
Good benchmarks are essential. A major effort has been underway in
the DaCapo group to put together a new benchmark suite. Plans are
to relicense this under the Apache license. The suite badly needs
new packaging and a new harness and is looking for someone to pick
up the ball and run with it. Many of the constituent benchmarks are
drawn from the Jakarta project.
http://www-ali.cs.umass.edu/DaCapo/gcbm.html
. Generalize object model abstraction [mmtk,ovm]
There are many different object models (ways of laying out an
object, its header and associated metadata). A good GC toolkit
should be able to abstract over the various object models a host VM
may implement. Providing a suitably high level abstraction without
performance penalty is an important item on the MMTk todo list.
This sort of generality is something the OVM project has focussed
on.
http://www.ovmj.org/
http://www.ovmj.org/ovmir.ps
. MMTk as .so [mmtk]
Build MMTk as a .so, ideally adding new pragmas so that barriers and
allocation sequeneces are materialized as inlined C in mmtk.h.
Builds on prior work by Robin Garner and Andrew Gray. Will allow
MMTk to be linked into C-based VM's.
http://cs.anu.edu.au/~Andrew.Gray/rmtk/
. jikes rvm opt modularization [jikesrvm]
The Jikes RVM optimizing compiler is one of the valuable aspects of
Jikes RVM. If it is to be reused by harmony it needs to be properly
modularized. This project will involve "normalizing" the code
(getting rid of Jikes RVM-specific idioms and ideosynchrosies) and
clearly defining the module. In addition to extracting one of the
most important
http://jikesrvm.sourceforge.net/userguide/HTML/optdetails.html
. remove dependency on jburg in jikesrvm [jikesrvm]
iburg is a widely used bottom up re-write tool used to produce code
generators. Jikes RVM added some extensions, known within jikes rvm
as jburg. There also exists a tool called jburg which is a java
implementation of the original burs work (not directly derived from
iburg, but written from scratch on the basis of the orginal Fraser,
Hansen and Proebsting paper.
http://jburg.sourceforge.net/
http://cvs.sourceforge.net/viewcvs.py/jikesrvm/rvm/src/tools/jburg/
http://www.cs.princeton.edu/software/iburg/
http://portal.acm.org/citation.cfm?id=151640.151642
http://www.cs.manchester.ac.uk/mscprojects/projects.05/jam.html
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
