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.
Pragmas.
http://jikesrvm.sourceforge.net/api/org/vmmagic/pragma/package-summary.html
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.
http://jikesrvm.sourceforge.net/api/org/vmmagic/pragma/InlinePragma.html
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).
http://jikesrvm.sourceforge.net/api/org/vmmagic/pragma/UninterruptiblePragma.html
Unboxed Types.
http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/package-summary.html
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.
http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/Address.html
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.
http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/ObjectReference.html
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
implemented!
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).
Cheers,
--Steve
