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 vmmagic
Date Wed, 25 May 2005 02:45:17 GMT
Perhaps it is worth saying a little more about vmmagic.

The basic idea is to provide the necessary extensions to Java for the
construction of a java-in-java virtual machine.  These fall into two
categories: pragmas (some for safety, some for performance) and
unboxed types.  In all cases, these are regular java expressions that
are noticed by the compiler as being "special", intercepted and
compiled to reflect the defined semantics of vmmagic.  Thus, for
example, when the compiler sees an instance of Address.loadInt(), it
compiles it into a load instruction.

Aside from satisfying the need to directly access memory, these types
are used to enforce type safety, provide us with unsigned word type
and abstract over issues such as the size of an address (32/64).  The
latter is extremely valuable in Jikes RVM where we support both 32 &
64 bit architectures.

I've written a few notes about the history of vmmagic below, but I
want to say right now that vmmagic has evolved and will continue to
evolve, particularly in light of new developments such as annotations
etc in J2SE 5.



  The magic pragmas can in principle be scoped at least three ways.
  Per-class (overloading the implements keyword), per-method
  (overloading the throws keyword), and intra-method (overloading the
  try catch keywords).  Presently we only use the first two.

  An example of a performance related pragma is InlinePragma, which is
  used to indicate that a method should always be inlined by the
  optimizing compiler.


  An example of a correctness related pragma is UninterruptiblePragma
  which ensures that the compiler does not allow a method to be
  interrupted for thread switching (by omitting yield points).


Unboxed Types.

  The Address type is used to provide raw memory access through its
  load<type>() and store<type>() methods.  It also provides a memory
  barrier abstraction with a prepare()/attempt() idiom.  Finally, it
  abstracts over address width (32/64).  Despite the appearance of a
  "value" field in the javadoc below, in fact the type is materialized
  by the compiler as a primitive 32/64 bit type, not an object, and
  its methods are reduced to the appropriate instructions (load, store
  etc), not method calls.


  The ObjectReference type is used to provide an abstraction over
  object identifiers (rather than using Address, which is somewhat
  like using void*).  In the case of Jikes RVM ObjectReferences are
  materialized as 32/64 bit primitive types with direct operations,
  with the toAddress() operator returning that same value (since Jikes
  RVM uses addresses as object identifiers).  However in a VM that
  used handles, an ObjectReference would map to a handle and
  toAddress() would dereference the handle.


For more information I suggest you browse the java doc, and if brave,
venture into the Jikes RVM compilers and see how the magic is actually

Brief history

   The use of magic dates back to the beginning of the Jikes RVM
   project (then known as Jalapeno).  I know of three major sources of
   refinement.  First the OVM group, and in particular Chapman Flack
   (Purdue), made significant improvements to the Jalapeno approach to
   magic. Perry Cheng (IBM Research) then wrote an initial version of
   the Address, Word and Extent classes and in doing so with Kris
   Venstermans (Ghent) and Dave Grove (IBM Research) was able to
   identify and fix all of the thousands of uses of "int" (for
   address) in the Jikes RVM codebase.  This was key to getting a 64
   bit port going.  Daniel Frampton (ANU) was responsible for
   packaging it as org.vmmagic, separating the unboxed and pragma
   types, and introducing new types including ObjectReference.  Most
   of the original pragma types were written by Stephen Fink and Dave
   Grove (IBM Research).



View raw message