harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] A list of drlvm enhancements and limitations
Date Tue, 17 Oct 2006 14:14:29 GMT
Hi Gregory,
    It is a good idea to put up a live list, thanks. Here are some
suggestions on the contents for development items in the VM/JIT. A few may
be almost done. We can fine tune...and add other work items as well

JIT Items
======
- GC related: WB support in Jitrino.opt

  Implement support of write barriers in the Jitrino.opt compiler. Write
  barriers are required to implement a generational GC. Currently WB are
  supported in Jitrino.JET only.

- JIT: HLO improvements in Jitrino

  A set of performance-oriented improvements:

  - Reduce overhead from Back Branch Polling - remove BBP from finite
    loops or reduce overhead if loop finiteness is undetermined.

  - Implement interface call devirtualization - based either on
    heuristics or on the edge profile or on the value profile. The latter
    requires implementation of the value profile.

  - Array Bounds Check Elimination - need to fix current ABCD algorithm and
    implement a new range check elimination optimization

  - Loop unrolling - Improve loop unrolling and the code produced after this
    optimization.


- JIT: New optimizations in Jitrino high-level optimizer.

  The Escape Analysis (EA) algorithm prototype is in Jitrino code.
  The following new optimizations could use EA information:

  - EA-based scalar replacement
  - EA-based on-stack allocation

- Improvement of calling conventions.

  Currently the IA-32 and Intel-64 CG uses calling conventions that pass all

  parameters on stack. Also, all used calling conventions require returning
  FP values in x87 register stack and do not support callee-saved SSE
  registers while all FP arithmetic is done using SSE/SSE2.

  Although aggressive inlining reduces the overhead performance can
  be improved in the following directions:
  - Passing arguments in GP and SSE registers
  - SSE-friendly calling conventions.
  - Pluggable calling conventions.

  Calling convention improvements require changes in all JITs and VM core.

- Branch optimization in IA32/Intel 64 CG.

  Analysis of the code generated by Jitrino on IA32 show that many
  unnecessary branches could be eliminated.

- Register allocation improvements and tuning.

  Currently there are 2 global register allocators in Jitrino:
  bin-packing and color graph. Further improvement of register
  allocation could be done in the following directions:

  - Profile-guided live-range splitting in the register allocators.
  - Tuning and enhancing the color graph RA.
  - Implementation of new register allocation schemes.

- IA-64 enabling.

  Jitrino.opt contains an IA-64 code generator but the rest of the system
  does not support this platform. Also, the Jitrino.opt code generator needs
  more platform-specific optimizations and tuning.

- X87 based floating point math.

  Currently all FP operations in Jitrino are implemented using SSE/SSE2
  except for the calling conventions which use x87 and a few other minor
  exceptions in Jitrino.opt to be fixed.

  If a processor does not support these technologies the system behavior
  is undefined.

- Jitrino front-end re-factoring (BC translator, HLO info, etc.)

  Re-factor Java bytecode translator in the Jitrino.opt to make the code
  clearer and simplify the used data structures.
  Improve HLO framework (SSA on-demand, cleanup on-demand etc.)

- DPGO: Bytecode-based edge profiling

  Currently edge profile information in the Jitrino.opt is mapped to the
  Internal Representation (IR) which makes profile sensitive to the IR
  transformations. Mapping profile (or IR) to the bytecode will remove such
  dependency. Then possibility to unify the IR-bytecode mapping used for
  profiling and JVMTI support should be also considered.


Core VM
=======

- bytecode verifier:
  Develop subroutine Verification

- JNI:
  JNI Weak References development

   Globalization: These are community tasks ( geir ) but not important for
product
-  Develop VM locale support
-  Unicode support for Java classes/method/field name


- Thread Manager:
  Develop synchronization protocol for JVM
  Implement of synchronization and other basic helpers for IPF
  remove "non system locks"

- Stack : Complete overflow handling support for Java and native code

- Tool Interface:
  Profiling implementation, in particular Heap iteration, in JIT mode

- Garbage Collection:
  The work in the garbage collection area is new gc_v5 functionality, and
bug fixing and removal of performance bottlenecks( SpecJBB2005 ) in GCV4.1.
The work on GC_v5 include:
  Generational GC with WB support
  LOS support
  Parallelization Support
  Debugging and verification framework
  Weak Reference and Finalizer Support

 ( Xiao Feng?)

- MMTk integration:
  Support for magic classes in Jitrino
  VM/JIT support for MMTk collectors including RSE and thread suspension

  ( Weldon, could you please add details?)

Thanks
















> On 10/16/06, Mikhail Loenko <mloenko@gmail.com> wrote:
> >
> > Once it's more or less ready let's point to that page from TODO on our
> > website
> >
> > Thanks,
> > Mikhail
> >
> > 2006/10/17, Gregory Shimansky <gshimansky@gmail.com>:
> > > Hello
> > >
> > > You know that drlvm was donated by Intel and there was some period of
> > time
> > > while drlvm was developed internally. We had an internal bugzilla
> > server to
> > > track the issues. In an effort to move all development to the open
> > this
> > > internal bugzilla will be closed.
> > >
> > > The database is quite big and contains a lot of valuable information
> > including
> > > still open bugs. There are many of them which are not exactly bug
> > reports,
> > > but requests for enhancements or limitation problems. These small
> > issues
> > > didn't make it to README because they are mostly minor and low
> > priority, but
> > > it is better to use information which we have already than rediscover
> > these
> > > problems again.
> > >
> > > So not to create a lot of garbage in JIRA like problem requests
> > without
> > > patches I think it is better to create something like a TODO list for
> > drlvm.
> > > Not exactly bugs, but more like known limitations list.
> > >
> > > To give you an example, vm/vmcore/src/init/properties.cpp contains a
> > #define
> > > MAX_PROP_LINE 5120 which is a maximum property length specified in
> > > vm.properties file. I am not even sure if this file still used,
> > probably not,
> > > but a buffer length limitation is still a bad thing.
> > >
> > > I think a good place for such list would be on wiki. I am going to
> > create a
> > > page for it so that everyone who has open bugs inside of Intel could
> > add a
> > > line or two describing a problem recorded in bugzilla. I have 3 like
> > these
> > > filed myself including the one I gave as an example.
> > >
> > > I don't know the number of such bugs overall, maybe it is not so big.
> > But
> > > before creating JIRAs for them I think it is better to collect a list
> > on
> > > wiki. What do you think?
> > >
> > > --
> > > Gregory Shimansky, Intel Middleware Products Division
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message