Skip to end of metadata
Go to start of metadata

The Maxine Project: VM Platform Requirements

To develop and use Maxine, you need:

  • Hardware requirements:
    • 500 MB free disk space
    • 2 GB RAM
    • A x86-64 processor
    • A display with a resolution of at least 1920x1200 is recommend for use of the The Maxine Inspector.
  • Software requirements:
    • Solaris, Solaris 11 Express, Linux, or Mac OS X.
    • An installation of JDK 1.7 or OpenJDK7. We have successfully built Maxine with JDK version 1.7.0_25. It should work with other 1.7.0 versions, but sometimes changes in the JDK code require modifications to Maxine. N.B. Maxine is no longer supported on JDK 1.6.
    • JUnit 4.0+.
    • On Solaris, you need the libproc.h header file from OpenSolaris. Due to licensing issues, we are prevented from supplying this file with our download. You need to copy it to Native/tele/solaris/ before building Maxine's C code on Solaris.
    • GNU make version 3.7.9 or later, which must be on your command path as gmake.
    • A C tool chain (i.e. compiler, preprocessor and linker). We have limited resources for testing C compiler support on a wide variety of platforms. The table below lists the C tool chains that known to work (or not) for each platform. Please help us expand this compatibility matrix by leaving a comment on this page when you try building Maxine on another platform.
    • Some of the support needed by the C tool chain on Mac OS X is obtained by installing Apple's Xcode tool suite. Apple recently changed the way Xcode gets downloaded and installed, and an additional step is now required beyond the standard installation. Open the Xcode application (located in the /Applications folder), open the Preferences pane, select the Downloads section, select the Components tab, and install "Command Line Tools".
Platform Supported C tool chain(s) Incompatible C tool chain(s)
OpenSolaris 2009.06 x64 Sun Studio 12 Update 1
gcc 4.3.2
gcc 3.4.3
Solaris 10 x64 Sun Studio 12  
Solaris 10 SPARCv9 Sun Studio 12  
Mac OS X 10.5 gcc 4.2.1  
Mac OS X 10.6 gcc 4.2.1  
Linux 2.6.* x64 gcc 4.3.3  

Inspector Look & Feel

As of February 2011, the Inspector's GUI toolkit defaults to the native Look & Feel (L&F) of the platform on which it runs, also known as the SystemLookAndFeel. Prior to Februry 2011, the Inspector was configured to use only the Java L&F, also known as Metal, also known as the CrossPlatformLookAndFeel. See also Available Look and Feels.

There are three ways to override the Inspector's selection of Look & Feel: two by using standard Java platform mechanisms and one by modifying Inspector source code.

  1. Command line: the argument -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel will force the Inspector to use the Java L&F as it did before (see Specifying the Look and Feel: Command Line).
  2. file: it is possible to change the platform default L&F by putting swing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel in the file, whose location is platform-specific (see Specifying the Look and Feel: File).
  3. the source line that formerly forced the Inspector to use the Metal L&F is still present; it is commented out and could be restored. See class com.sun.max.ins.MaxineInspector.

Java considerations under Mac OS X

Required version

Maxine requires Java 1.7, which is not the default installed Java on Mac OS X. You must download JDK 7 from the Oracle Site, and ensure that JDK 1.7 is the default Java when building and running Maxine.

Inspector considerations under Mac OS X

Elevated privileges required

The The Maxine Inspector makes use of the task_for_pid() system call to control the Maxine process being debugged/inspected. Mac OS X restricts use of this call to processes that are either owned by root or whose group id is the procmod group. Prior to Mac OS X 10.6 (i.e. Snow Leopard), a work around for this was to setgid procmod the executable that runs the Inspector, i.e. the java binary in your JDK 1.6 installation. While this worked, it opened security vulnerabilities for other Java programs run by the same executable. A better solution is to require the Inspector to be run as root. This is now enforced in the mx script by having the Inspector launched via sudo.

One other side-effect of this security policy on Mac OS X is that the Inspector cannot be launched via an IDE unless the IDE supports prefixing the Java executable it uses with sudo. If you need to debug the Inspector on Mac OS X, then you must launch it externally to the IDE in such a way that it suspends itself and waits for a debugger to connect to it. This can be achieved via the mx script as follows:

% mx -dbg 8000 inspect ...
Listening for transport dt_socket at address: 8000

You now need to start a remote debugging session in the IDE that connects to port 8000 (or whatever port number you choose). For example, the steps for doing this in Eclipse are:

  1. From the main menu bar, select Run > Debug Configurations... to open the Debug Configurations dialog.
  2. Double-click the Remote Java Application node to create a new launch configuration.
  3. In the Project field under the Connect tab, select (or type in) the Inspector project.
  4. Set the Host and Port fields to localhost and 8000 respectively.
  5. Press the Debug button.
The ideal solution would be to use the Authorization Services on Mac OS X to enable the Inspector process to dynamically elevate its privileges at run time. The Inspector includes some code (discussed in more detail here) that attempts to use these services but unfortunately, it doesn't yet work for unknown reasons. Apparently, we are not the only ones to have encountered this problem.

Inspector considerations under OpenSolaris

Currently, the JDK that ships with OpenSolaris does not include a 64-bit version of the native code used by the accessibility framework. Given that the Inspector has its own native 64-bit libraries, the JVM running it has to be launched in 64-bit mode (i.e. the -d64 VM option is used). It appears that all Swing-based apps try to load the accessibility library at some point and so the Inspector crashes at this point with an error like this:

Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jdk/instances/jdk1.6.0/jre/lib/ext/ java: fatal: /usr/jdk/instances/jdk1.6.0/jre/lib/ext/ wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

Until the JDK on OpenSolaris includes the missing 64-bit JNI library, the workaround according to this thread on the OpenSolaris forums is to rename or remove /usr/java/jre/lib/ from the system.

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.