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.
- Glossary of Maxine terminology and concepts
- Boot heap
- Bytecode breakpoint
- C1X compiler
- C1X4HotSpot compiler (deprecated)
- Code eviction
- CompilationScheme (removed)
- CPS compiler (removed)
- Dynamic hub
- Grip (removed)
- GuestVM (renamed)
- HOM layout
- Hybrid object representation
- Immortal memory
- Injected fields
- JDK interoperation
- JIT (removed)
- Logging and Tracing
- The max script (removed)
- Maxine Assembler System
- Maxine packages
- Maxine Virtual Edition
- Maxwell Assembler System
- Method substitution
- The mx script
- OHM layout
- Primordial thread (deprecated)
- Static hub
- Static tuple
- Stop positions
- T1X compiler
- Target method
- Thread local
- Thread-local variable
- Thread locals area (TLA)
- Thread-local allocation buffer (TLAB)
- Thread locals block (TLB)
- VM Operation
The VM's runtime representation of a Java language entity (e.g. class, method, or field).
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.
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.
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.
See Maxine packages.
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"
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.
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.
Renamed to Graal
The VM's runtime representation of a Java class.
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.
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.
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.
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 com.sun.cri.package-info.java
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
The VM's runtime representation of a Java field.
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!
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?
Renamed to Maxine Virtual Edition
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.
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.
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.
See the ImmortalHeap class as well as the various ImmortalHeap_* classes that test this functionality.
See class com.sun.max.vm.heap.ImmortalHeap
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.
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.
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.
A flexible, extensible mechanism for logging and tracing VM activity.
A shell script that provided a command line alternative to IDEs for many important development functions, replaced by the mx script.
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.
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.
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.
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.
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
Now called the Maxine Assembler System
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.
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.
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.
A Python program that provides a command line alternative to IDEs for many important development functions. mx replaced the max script in November, 2011.
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.
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.
See also "Maxine Threads and Safepoints"
A data structure that indicates stack locations that hold references to the heap.
Iterative data flow analysis via abstract interpretation
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.
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.
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.
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.
A special kind of heap object that holds the class variables (static fields) for a class in the VM.
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.
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.
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.
See abstract com.sun.max.vm.compiler.target.TargetMethod
A VM representation of a native thread on which execution can take place.
Nickname for a 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.
A portion of heap storage reserved for allocation by a single thread, permitting synchronization-free allocation.
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.
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.
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.
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