Skip to end of metadata
Go to start of metadata

Glossary of Maxine terminology and concepts

Welcome to the Maxine Glossary: a very informal and evolving set of brief notes to help orient newcomers to some of the terminology and concepts we use when talking about the Maxine VM. Please feel free to add comments to this page (you'll need a free account) or to write to us with comments and suggestions. It is definitely a work in progress.

You might also want to browse the "Maxine FAQ".

We thank our collaborators who have been contributing documentation as well; we link to it from this page and others whenever possible.


The VM's runtime representation of a Java language entity (e.g. class, method, or field).
Read more.


A specially marked field or method in a VM class that refers to a field or method in another class that would otherwise be inaccessible due to Java language access control rules. Used mainly for VM access to private members of JDK classes.
Read more.


The Maxine VM code makes heavy use of Java Annotations as a form of language extension. These extensions, which are recognized and treated specially by the Maxine compilers, permit the kind of low-level, unsafe programming that is otherwise not possible with Java. By using the Java annotation mechanism, which is a first class part of the language, the Maxine sources are completely compatible with Java IDEs. See package com.sun.max.annotate.

Here are a few of the important Maxine annotations (follow the links to see the source file comments for full specifications of these):

  • @ALIAS: denotes a field or method as an alias, which can be used to access a field or method in another class that would otherwise be inaccessible due to Java language access control rules.
  • @BUILTIN: denotes a method whose calls are translated directly by the compiler into machine code
  • @C_FUNCTION: denotes a native function for which a lightweight JNI stub should be generated
  • @CONSTANT: denotes a field whose value is final before it's first read (i.e. a stationary field)
  • @CONSTANT_WHEN_NOT_ZERO: denotes a field whose value is final once it is non-zero
  • @FOLD: calls to these methods are evaluated (as opposed to translated) at compile time
  • @INLINE: forced inlining
  • @INSPECTED: used by an offline tool to generate field and method accessors for the Maxine Inspector.
  • @METHOD_SUBSTITUTIONS: denotes a class containing MethodSubstitutions
  • @NEVER_INLINE: denotes a method that this compiler must never inline
  • @SUBSTITUTE: denotes a MethodSubstitution
  • @UNSAFE: marks a method that requires special compilation; some other annotations imply @UNSAFE

See also: Maxine Assembler System.

Boot heap

An object heap embedded in the VM boot image. It is a normal heap, with the exception that objects in it never move (although they may become permanent garbage). As the name implies, the objects in this heap are those allocated during boot image generation. The boot image is really just this heap plus a little meta-data in front.
Read more.


See Maxine packages.


The process of loading and executing a boot image of Maxine, up to the point where the VM is ready, either to execute a specified application class or other action specified by the run scheme.

Currently a boot image of Maxine is not a native executable but just a binary blob containing machine code and data for a dedicated target platform. Thus a boot image is not executable by itself. To start it a very small native C application is required.
See: Boot Image
See also: "Understanding Maxine's bootstrapping"

Bytecode breakpoint

A breakpoint set in the inspector, whose location is specified abstractly in terms of a location in the a method's bytecode. The Inspector will endeavor to set a breakpoint in the corresponding machine code location (now supported at method entry only, i.e. location 0) in every compilation of the method during the session, past or future. Such a breakpoint can even be set before a class is loaded.
Read more


C1Visualizer is a visualization tool for the internal data structures of the Java HotSpot client compiler (C1); it can also be used with C1X.
Read more

C1X compiler

The optimizing compiler for the Maxine VM. C1X replaced the original CPS compiler whose performance and workability turned out to be insufficient for the goals of the project. The replacement was complete in April 2011, at which time CPS was removed from the Maxine build.

C1X was developed by the Maxine group, derived by porting the HotSpot Client compiler (C1). C1X is designed to be runtime independent through a narrow and strict compiler/runtime interface (defined in the CRI project). For example, C1X is separated from the runtime representation of types, classes, methods, fields, and constant pools of a particular VM by a set of interfaces that define only the methods used by the compiler in translating code. Similarly, the runtime is separated from the implementation details of C1X through a smaller but complimentary set of interfaces that represent compiler output such as generated machine code, exception handler tables, reference maps, and deoptimization information.

C1X also embodies the language extensions needed to provide critical (and unsafe) operations supporting the VM; these are expressed as Java annotations, so the VM source code can be developed using standard Java IDEs.

Read more

C1X4HotSpot compiler (deprecated)

Renamed to Graal


The VM's runtime representation of a Java class.
Read more.

Code eviction

Memory management applied to the VM's cache of method compilations, especially important in Maxine since the absence of an interpreter requires that every method be compiled, even if only executed once. Code eviction was added to Maxine in Fall 2011, for machine code generated by the T1X compiler.
Read more


Manager for an adaptive compilation system with multiple compilers with different compilation time / code quality tradeoffs. It encapsulates the necessary infrastructure for recording profiling data, selecting what and when to recompile, etc. It replaced the CompilationScheme in October, 2011.
Read more.

CompilationScheme (removed)

A Maxine Scheme: replaced by the CompilationBroker in October, 2011.

CPS compiler (removed)

The original compiler for the Maxine VM, written in a continuation passing style. Compilation is central to the Maxine VM, as there is no interpreter, which in turn requires bootstrapping from a binary boot image produced by the compiler.

The CPS compiler contains a number of extensions, expressed as Java annotations, that effectively extend the Java language with a number of critical (and unsafe) programming constructs. Because these extensions are expressed only as annotations, the VM sources can be developed using a standard IDE.

Experience taught that the performance and workability of CPS were insufficient for the goals of the project, and it was replaced by the C1X compiler in April 2011.
Read more.


A new Compiler Runtime Interface, developed as part of the integration of the C1X compiler, designed to be both narrow and strict.

  • The compiler is separated from the runtime representation of types, classes, methods, fields, and constant pools of a particular VM by a set of interfaces that define only the methods used by the compiler in translating code.
  • The runtime is separated from the implementation details of the compiler through a smaller but complimentary set of interfaces that represent compiler output such as generated machine code, exception handler tables, reference maps, and deoptimization information.

See C1X, XIR
See file
See also: Titzer, B. L., Würthinger, T., Simon, D., and Cintra, M. Improving compiler-runtime separation with XIR. SIGPLAN Not. 45, 7 (Jul. 2010), 39-50. DOI

Dynamic hub

See Hub.


The VM's runtime representation of a Java field.
Read more.


The goal of this project (formerly named C1X4HotSpot) is to integrate C1X with the HotSpot JVM. In doing so the C1X compiler and the compiler runtime interface (CRI) should get more generic and it means improvements to C1X benefit 2 VMs instead of 1. The ultimate goal is to show that a substantial VM subsystem (the compiler) of a C++ based JVM can be developed in Java without causing any (or very minimal) additional overhead at runtime.

Why the name Graal? This project is a holy quest for adding meta-circularity to an industrial-strength JVM!

Read more

Grip (removed)

An abstraction in Maxine's original design that provided Reference-like access to objects, but without write barriers. Experience taught that the abstraction added too little value to justify the complexity, and it was removed September, 2010.
See: Why were Grips removed?

GuestVM (renamed)

Renamed to Maxine Virtual Edition

HOM layout

An implementation of object memory layout described as Header-Origin-Mixed.
Read more.


A Maxine Scheme: a Java interface that specifies the behavior of the object heap with respect to allocation, and garbage collection.
Read more


See: Maxpath


A special kind of heap object that summarizes low-level information about the content of class instances. The hub holds information, derived from a class's class actor, that must be immediately accessible (one memory hop) from each class instance.
Read more.

Hybrid object representation

One of three fundamental ways to represent objects in the Maxine VM heap: a combination of fields and arrays (which cannot be described in the standard Java language) used to represent Maxine hubs.
Read more.


One of the great productivity advantages of the Maxine VM when compared to other research VMs is that it can be developed, built, and run from the highly evolved modern Integrated Development Environments for Java: Eclipse, Netbeans, and IntelliJ.
Read more.

Immortal memory

See the ImmortalHeap class as well as the various ImmortalHeap_* classes that test this functionality.

See class com.sun.max.vm.heap.ImmortalHeap

Injected fields

During startup the VM synthesize and injects additional fields into core JDK classes. Injected fields typically link instances of JDK objects to their internal VM representation.
Read more


The Maxine Inspector is the essential all-in-one companion tool for Maxine VM development. It plays many roles:

  • object, class, and method browser;
  • code views include disassembled machine code, disassembled bytecode, and source;
  • low-level debugger (imagine gdb or dbx) with visual displays of threads, registers, stacks, stack frames, thread local values, breakpoints, memory watchpoints, etc.;
  • intermediate representation debugger;
  • source-level Java debugger (eventually); and
  • serviceability agent (eventually).

For a detailed user's view of the Inspector, please visit the Maxine Inspector web page, where you'll find video demonstrations, detailed discussion of the Inspector's functionality (with screen shots), and instructions for downloading and building.

For a technical overview of the Inspector's mechanisms for communicating with the VM, please see Inspector-VM Interaction.


The VM does not have an interpreter; it only runs compiled code.
See: Bootstrap

JDK interoperation

The Maxine VM is designed to work with a standard, unmodified JDK, which requires special machinery for dealing dynamically with important JDK classes. This machinery is implemented by compiler extensions, configured by Annotations.
Read more

JIT (removed)

The original template-based baseline compiler used by the Maxine VM, replaced in April 2011 by T1X.
Read more


Implementations bound to the interface com.sun.max.vm.layout.LayoutScheme specify object memory layouts. Two are currently implemented: OHM and HOM.
Read more.

Logging and Tracing

A flexible, extensible mechanism for logging and tracing VM activity.
Read more

The max script (removed)

A shell script that provided a command line alternative to IDEs for many important development functions, replaced by the mx script.

Maxine Assembler System

The code generating system used by Maxine's obsolete CPS compiler but not by its replacement, the C1X compiler. Although the assembler will eventually be removed along with the CPS compiler, the disassembler part of this system will remain in use by the Inspector as well as the C1X compiler.
Read more

Maxine packages

A mechanism for treating groups of classes in Java package as a de facto "module" for purposes of system configuration and evolution. This requires implementing more functionality than is provided by the Java language via java.lang.Package.

This main application of this mechanism is to define the classes to be including during Maxine boot image generation, and in particular to specify which implementations to bind to VM schemes.

Strictly speaking, a Maxine package is a collection of classes in a Java package that includes a class named Package. The class Package must extend class com.sun.max.config.BootImagePackage in order to be considered for inclusion in the VM. The Package class, other then acting as a marker, may contain additional specifications directed at the Maxine package system. In many cases, however, trivial Package class can be synthesized dynamically and need not be explicitly defined.

Maxine Virtual Edition

Maxine on Xen, a companion Oracle Labs project that hosts the Maxine VM in a hypervisor domain instead of on a traditional operating system. Formerly named Guest VM


This is a project led by Michael Bebenita at UC Irvine, doing trace-compilation on Maxine.
This compiler is part of Maxine but not actively used by us. It is referred to as Hotpath in the Maxine sources.

Maxpath currently relies on the backend of the (soon to be deprecated/deleted) CPS compiler. However, it will be retargeted to C1X at some point.

See also: Bebenita, M., Chang, M., Wagner, G., Gal, A., Wimmer, C., and Franz, M. 2010. Trace-based compilation in execution environments without interpreters. In Proceedings of the 8th international Conference on the Principles and Practice of Programming in Java (Vienna, Austria, September 15 - 17, 2010). PPPJ '10. ACM, New York, NY, 59-68. DOI

Maxwell Assembler System

Now called the Maxine Assembler System


The Maxine Project source code resides in a Mercurial repository.
Read more


In a conventional VM implementation (left in the figure below) there is a language barrier between the language being implemented (Java in the figure) and the implementation language (C++). No such barrier exists in Maxine, where the VM is itself implemented in the language being implemented.

See also: Ungar, D., Spitz, A., and Ausch, A. 2005. Constructing a metacircular Virtual machine in an exploratory programming environment. In Companion To the 20th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (San Diego, CA, USA, October 16 - 20, 2005). OOPSLA '05. ACM, New York, NY, 11-20. DOI


The VM's runtime representation of a Java method.
Read more.

Method substitution

Guided by Annotations, the Maxine VM substitutes certain JDK methods with alternative implementations and compiles those in their stead. It does not matter whether the original methods are native.
Read more.


A Maxine Scheme: a Java interface that abstracts the way in which monitors are implemented. This covers both the translation of the monitorenter and monitorexit bytecodes and the implementation of wait and notify methods.
Read more.

The mx script

A Python program that provides a command line alternative to IDEs for many important development functions. mx replaced the max script in November, 2011.
Read more

OHM layout

An implementation of object memory layout described as Origin-Header-Mixed.
Read more.

A documentation class, following Javadoc convention, for the classes and interfaces in a Java package; this is especially encouraged for packages that constitute Maxine package and serve as modules for VM configuration.

A class used for configuration purposes by the Maxine Package mechanism.
See also: boot image generation and Schemes.

Primordial thread (deprecated)

Deprecated name for the main thread running in the VM process. The main thread executes all the preliminary steps taken during VM startup, up until the creation and running of the first Java thread. It was until February 2011 distinct from the thread on which the Java main method is called. After that the two threads are one and the same.
Read more.
See also "Maxine Threads and Safepoints"


A data structure that indicates stack locations that hold references to the heap.
Read more.


Iterative data flow analysis via abstract interpretation
Read more


Implementations bound to the interface com.sun.max.vm.reference.ReferenceScheme specify how objects are accessed for mutator use.
Read more.


A Maxine Scheme: a Java interface that defines what the VM is configured to execute after it has started its basic services and is ready to set up and run a language environment, e.g. a Java program.
Read more.


A special instruction in compiled VM code where a thread can be frozen with certain guarantees about the consistency of the heap and the thread's stack, guarantees necessary for safe garbage collection.
Read more.
See abstract class com.sun.max.vm.runtime.Safepoint
See also: "Maxine Threads and Safepoints"


A Java interface that specifies a configurable subsystem of the VM. A complete VM configuration includes bindings to a specific implementation of each scheme. For example, the Maxine code base currently contains 2 alternative Layout scheme bindings: OhmLayoutScheme and HomLayoutScheme.
Read more


Snippets are designed to provide a clean separation between the runtime system and compiler in a JVM. A clean separation allows either component to be modified or extended independently in the pursuit of features or optimization. Furthermore, snippets are designed to isolate the implementation of runtime features from each other. For example, the implementation of virtual dispatch need not be aware of the object model or memory management implementation.

The implementation of Java snippets in Maxine is currently heavily tied to the CPS compiler. Their whole design will be revisited during the process of converting to the C1X compiler.

Read more

Static hub

See Hub.

Static tuple

A special kind of heap object that holds the class variables (static fields) for a class in the VM.
Read more.

Stop positions

A list of call and Safepoint instructions within a target method. These locations correspond to all possible addresses the instruction pointer of a frame may have when its thread is stopped at a safepoint. The location of all references on the stack are precisely known when at a stop position.
Read more

T1X compiler

A template-based baseline compiler. T1X serves as Maxine's first line of execution, since the VM has no interpreter. The compiler's goal is to produce code as fast as possible.
Read more

Target method

The VM entity that contains some machine code produced by one of Maxine's compilers. It also contains all the other data required by the VM for some machine code. The corresponding concept in HotSpot is an nmethod.
Read more
See abstract


A VM representation of a native thread on which execution can take place.
Read more.

Thread local

Nickname for a thread-local variable.

Thread-local variable

A per-thread implementation variable in the VM, also known as a "thread local", not to be confused with language-level Thread-local storage, which is supported in Java by the class java.lang.ThreadLocal.
Read more.

Thread locals area (TLA)

A per-thread storage area where thread-local variables supporting the VM implementation are stored.
Read more.

Thread-local allocation buffer (TLAB)

A portion of heap storage reserved for allocation by a single thread, permitting synchronization-free allocation.
Read more.

Thread locals block (TLB)

A per-thread memory allocation, separate from the thread's stack, where thread-local variables, the stack reference map, and other implementation data are stored.
Read more.


The mechanism used to defer binding a call site to a target method. When compiling a call, an address is needed for the machine level call instruction. One option is to eagerly resolve the callee during compilation of the call but this will end up compiling the world! Instead, a piece of code is called that knows how to find and compile (if necessary) the intended target method and redirect the call there. For static calls, the call site itself is patched so that subsequent calls go straight to the resolved method. For virtual calls, the trampoline patches the entry in the relevant dispatch table.


One of three fundamental ways to represent objects in the Maxine VM heap: a collection of values used (in combination with a header) to represent an ordinary Java object instance.
Read more.

VM Operation

An operation that can be performed on one or more target threads in the VM, carried out by a specially dedicated threads. A VM operation is normally performed after the target threads are at a safepoint.
Read more


XIR is a machine-independent assembly-level language for specifying the VM-dependent implementation of Java bytecodes for the C1X backend. It is part of the compiler-runtime separation introduced with C1X. A VM (such as Maxine) supplies XIR for each of the complex bytecodes as C1X compiles them.
Read more

See also: Titzer, B. L., Würthinger, T., Simon, D., and Cintra, M. 2010. Improving compiler-runtime separation with XIR. SIGPLAN Not. 45, 7 (Jul. 2010), 39-50. DOI

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.

The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.