harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Blackburn <Steve.Blackb...@anu.edu.au>
Subject Work items
Date Fri, 27 May 2005 21:30:54 GMT
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?


. 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


. 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).


  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


. 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.


. 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.


. 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


. 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.


. 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


. 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.


View raw message