Here are some of the most frequently asked questions, along with answers that have been updated as the project evolves. You might also want to browse the Maxine "Glossary <./Glossary>
".
No. Maxine is designed to run with openJDK.
Maxine provides abstractions for coarse-grained configurability of many VM subsystems, which we call schemes. For example, the static and runtime compilers, garbage collector, reference representation, object layout, monitor implementation, are all configurable with schemes.
Currently Maxine employs a semi-space collector as the default. As with many other parts of the Maxine architecture, garbage collection is abstracted as a separate scheme with limited interactions with other schemes. We also aim to make the garbage collector scheme MMTK compatible.
Essentially none. See t1x-compiler-label
.
No; Maxine does not use green threads. Maxine uses native threads and a state-of-the-art safepoint mechanism for preemption. See Threads <./Threads>
.
No, instead we use the The Maxine Inspector for debugging and inspecting the VM while it is running.
Maxine can be built and run from the command line, no special development environment is needed.
The Maxine distribution provides an advanced variant of the Project Maxwell Assembler System, now called the Maxine Assembler System.
Yes, some examples include Jikes RVM, Joeq, OVM, and Moxie. The design of Maxine has benefited from these previous systems and enjoys the advantage of the new source language features in Java 5.0, particularly annotations and generics.
The simplest way to get application suspend/resume currently is to run Guest VM (Maxine on Xen). Suspend/resume is built into the hypervisor support and "just works". The Guest VM is server-side only though, no GUI at this point.
Maxine doesn't do interpretation. It instead uses a very fast baseline compiler. See t1x-compiler-label
.
Exception in thread "main" java.lang.UnsatisfiedLinkError: no hosted in java.library.path
The native library named "hosted" is used during the boot image generation to get information on the host platform. Very likely this has not been built for some reason.
First, be sure that you have a C development environment installed. Also ensure that the CDT plugin is installed if you are using Eclipse.
Lastly, try rebuilding the native code:
mx build -clean com.oracle.max.vm.native
Re: changeset 4423
The original rational for Grips was to provide an abstraction for object references that does not involve write barriers. Apart from that, it was pretty much an exact mirror of the ReferenceScheme
. The thinking was that the GC should be written against grips as it does not need to update write barriers. However, it turns out that object reference fix up is done via Pointers in the current GC implementations and I don't see why this won't/can't be true for any other GC. That is, we had a whole extra (and confusing) abstraction whose whole reason for existence was not being used! Additionally, even if references were being fixed up via Reference.setReference(...)
and Reference.writeReference(...)
instead of Pointer.setReference(...)
and Pointer.writeReference(...)
there is still no need for an extra abstraction. It would be far simpler to annotate the method(s) doing the update with an annotation (e.g. @NO_BARRIERS
) that would instruct the compiler not to insert write barriers.
Of course, Maxine's abstractions should support more than just write barriers for generational GCs. Other interesting barriers include read barriers for concurrent GCs, read & write barriers for all data types in an software transactional memory implementation, etc. I cannot say for certain that the support for these is sufficient right now, but I'm confident they can be programmed without grips.
The VM is almost entirely passive with respect to the Inspector process. There is no internal agent; the VM neither sends nor receives messages; in fact the VM barely knows that it is being inspected. Other than process controls (thread management, start, stop, set breakpoints, etc.), the Inspector works mostly by reading from VM memory. However, VM code is arranged in some places to make inspection easier, and there are a few critical places where the VM does respond to information written into its memory by the Inspector. See Inspector-VM Interaction <./Inspector-VM-Interaction>
.
Until February 2011 the original thread in a new Maxine VM process was known as the primordial thread; its job was to execute the preliminary steps needed to bootstrap the VM and then wait until the Java VM exited. From February 2011 onward, the original process thread eventually becomes the main thread, i.e. the thread on which the Java main thread runs. See Threads <./Threads>
.