JikesRVM

Page edited by Erik Brangs - "added merging of MRP changes as a goal" General project statusJikes RVM is currently the most popular platform for virtual ... [More] machine research. This popularity is reflected in the particpation on the mailing lists where most questions can be answered.Memory management research is a particular strength of the Jikes RVM. The Memory Management Toolkit (MMtk) provides a well-rounded selection of garbage collectors and the compiler replay feature enables researchers to control mutator variation. The MMTk test harness can be used to test collectors.In contrast to this, the compilers are currently a weak spot in the Jikes RVM. For example, the Static Single Assignment (SSA) form in the compilers is currently disabled because of bugs.The Jikes RVM is not state-of-the-art in some areas. In particular, Jikes RVM currently does not provide 64-bit Intel Support. Another big limitation is the lack of support for the OpenJDK class library. The project has received community contributions to improve those shortcomings but the code is not yet in the mainline. The Jikes RVM would also profit from efforts directed to stability improvements and bugfixes. For example, Jikes RVM currently cannot run all of the Dacapo 9.12 benchmarks.The Jikes RVM team aims to provide at least one release every year.Note: The information on this page refers to the status in the code repository and not to the status in the current release.Note: If you want to help, please see How to Help or inquire via the mailing lists.Near-term goalsAdd support for the OpenJDK class librariesAdd Intel 64-bit supportPreliminary long-term goals (still need further discussion)Improve stabilityImprove compliance with JVM specWrite unit tests for all classesImprove and extend test suitesAdd support for relevant new platforms (ARM?)Merge relevant changes from MRPDetailed project statusThis section provides more detailed project status information for the components. If you think an important point is missing here, please contact us via the mailing lists.BenchmarksDaCapo 2006-MR-2 runs on Jikes RVMSome benchmarks of DaCapo 9.12 workParts of SPECjvm2008 work (see RVM-484)CommunityJikes RVM has a large community in its intended audience (researchers)Core team consists wholly of volunteers: no paid developersJikes RVM is currently not packaged for any major distributionMemory ManagementGenerational Immix (the default collector) is very stableThe other collectors are reasonably stable but have some bugs (as shown by the regression tests)Notable omissions in the collector choices include Baker-style collectors, the Compressor and on-the-fly collectorsRuntimeThe runtime is reasonably modular but it doesn't make very good use of interfacesJikes RVM currently does not follow the JVM specificationSeveral features normally found in commercial JVMs are not implemented: strictfp, JMX and JVMTI are currently unsupportedAdaptive Optimization SystemThe AOS provides a good level of control via compiler replayThe AOS provides clear extension pointsJikes RVM currently uses only one compilation thread at runtime and the current AOS model does not support multiple compilation threadsThe provided AOS models do not support Feedback-Directed OptimizationsCompilersSSA form is disabled. Scalar SSA form may be fixable; Heap SSA form is considered too brokenMany optimizations are disabled because they rely on SSA or are considered too buggySome standard optimizations are missing, e.g. Global Array Bound check eliminationJava Memory Model (JMM) is not correctly implementedInfrastructureRegression tests are run regulary. The results are displayed with Cattrack, a Ruby-on-Rails application.There's currently no infrastructure for CI: Core team members need to ensure they run the pre-commit tests themselves.More regression machines would be useful, in particular PowerPC machines that can be accessed by all team membersCurrently no code review tools in useSome unit tests (via JUnit) exist but most classes don't have unit tests View Online · View Changes Online [Less]

Page edited by Erik Brangs - "coding style for assertions is now checked automatically; rename status link for Windows port from WIP to NYI" This guide ... [More] describes how to build Jikes RVM. The first section is an overview of the Jikes RVM build process and this is followed by your system requirements and a detailed description of the steps required to build Jikes RVM.Using builditOnce you have things working, as described below, the buildit  script will provide a fast and easy way to build the system.  We recommend you get things working as described below first, so you can be sure you've met the requisite dependencies etc.OverviewCompiling the source codeThe majority of Jikes RVM is written in Java and will be compiled into class files just as with other Java applications. There is also a small portion of Jikes RVM that is written in C that must be compiled with a C compiler such as gcc.  Jikes RVM uses Ant version 1.7.0 or later as the build tool that orchestrates the build process and executes the steps required in building Jikes RVM.Installation of AntJikes RVM requires a complete install of ant, including the optional tasks. These are present if you download and install ant manually. Some Linux distributions have decided to break ant into multiple packages. So if you are installing on a platform such as Debian you may need to install another package such as 'ant-optional'.Generating source codeThe build process also generates Java and C source code based on build time constants such as the selected instruction architecture, garbage collectors and compilers. The generation of the source code occurs prior to the compilation phase.Bootstrapping the RVMJikes RVM compiles Java class files and produces arrays of code and data. To build itself Jikes RVM will execute on an existing Java Virtual Machine and compiles a copy of it's own class files into a boot image for the code and data using the boot image writer tool. The set of files compiled is called the Primordial Class List. The boot image runner is a small C program that loads the boot image and transfers control flow into Jikes RVM.Class librariesThe Java class library is the mechanism by which Java programs communicate with the outside world. Jikes RVM has configurable class library support, the most mature of which is the the GNU Classpath class library. In the release version of Jikes RVM is support for the Apache Harmony class library.For GNU Classpath, the developer can either specify a particular version of GNU Classpath to use. By default the build process will download and build GNU Classpath.Setting the ant property classlib.provider to Harmony (see how to define ant properties) will change the build process to download and build the Apache Harmony class library.Target RequirementsJikes RVM is known to build and work on certain combinations of instruction architectures and operating systems. The following sections detail the supported architectures and operating systems.Architectures The PowerPC (or ppc) and ia32 instruction set architectures are supported by Jikes RVM.IntelIntel's Instruction Set Architectures (ISAs) get known by different names:IA-32 is the name used to describe processors such as 386, 486 and the Pentium processors. It is popularly called x86 or sometimes in our documentation as x86-32.IA-32e is the name used to describe the extension of the IA-32 architecture to support 8 more registers and a 64-bit address space. It is popularly called x86_64 or AMD64, as AMD chips were the first to support it. It is found in processors such AMD's Opteron and Athlon 64, as well as in Intel's own Pentium 4 processors that have EM64T in their name.IA-64 is the name of Intel's Itanium processor ISA.Jikes RVM currently supports the IA-32 ISA. As IA-32e is backward compatible with IA-32, Jikes RVM can be built and run upon IA-32e processors. The IA-64 architecture supports IA-32 code through a compatibility mode or through emulation and Jikes RVM should run in this configuration.Operating SystemsJikes RVM is capable of running on any operating system that is supported by the GNU Classpath library, low level library support is implemented and memory layout is defined. The low level library support includes interaction with the threading and signal libraries, memory management facilities and dynamic library loading services. The memory layout must also be known, as Jikes RVM will attempt to locate the boot image code and data at specific memory locations. These memory locations must not conflict with where the native compiler places it's code and data. Operating systems that are known to work include AIX, Linux and OSX. At one stage a port to win32 was completed but it was never integrated into the main Jikes RVM codebase.Note: Current implementation of Jikes RVM implies that system native libraries (like GTK+) have been compiled with frame pointers. Most of Linux distribution have frame pointers enabled in most of the packages, but some explicitly use -fomit-frame-pointer thus producing the library that can't be used with JikesRVM. See this issue for example.Support MatrixThe following table details the targets that have historically been supported and the current status of the support. The target.name column is the identifier that Jikes RVM uses to identify this target.target.nameOperating SystemInstruction ArchitectureAddress SizeStatusia32-linuxLinuxia3232 bitsOKia32-osxOSXia3232 bitsOKia32-solarisSolarisia3232 bitsOKia32-cygwinWindowsia3232 bitsNYIppc32-aixAIXPowerPC32 bitsOKppc32-linuxLinuxPowerPC32 bitsOKppc32-osxOSXPowerPC32 bitsOKppc64-aixAIXPowerPC64 bitsOKppc64-linuxLinuxPowerPC64 bitsOKx86_64-linuxLinuxia3232 bitsSee note belowx86_64 configurations are actually 32-bitx86_64 is currently only supported using the legacy 32bit addressing mode and instructions (track progress on full 64bit support here). You need to install the 32-bit versions of the required libraries to build and use the x86_64 configurations.Tool RequirementsJava Virtual MachineJikes RVM requires an existing Java Virtual Machine that conforms to Java 6.0 such as Oracle JDK 1.6, OpenJDK/IcedTea 6 or IBM SDK 6.0. We also aim to support the Java 7.0-conformant versions of these virtual machines.Some Java Virtual Machines are unable to cope with compiling the Java class library so it is recommended that you install one of the above mentioned JVMs if they are not already installed on your system. The remaining build instructions assume that a suitable Java Virtual Machine is on your path. You can run "java -version" to check you are using the correct JVM.AntAnt version 1.7.0 or later is the tool required to orchestrate the build process. You can download and install the Ant tool from http://ant.apache.org/ if it is not already installed on your system. The remaining build instructions assume that $ANT_HOME/bin is on your path. You can run "ant -version" to check you are running the correct version of ant.C and C++ compilersThe Jikes RVM build assumes that the GNU Compiler Collection is present on the system. Most modern *nix environments satisfy this requirement.BisonAs part of the build process, Jikes RVM uses the bison tool which should be present on most modern *nix environments.PerlPerl is trivially used as part of the build process but this requirement may be removed in future releases of Jikes RVM. Perl is also used as part of the regression and performance testing framework.AwkGNU Awk is required as part of the regression and performance testing framework but is not required when building Jikes RVM.Extra tools recommended for Solarispkg-get will greatly simplify installing GNU packages on Solaris. Our patches require that GNU patch is picked up in preference to Sun's, to achieve this, for example, you can create a symbolic link to /usr/bin/gpatch from /opt/csw/bin/patch and make sure /opt/csw/bin is in your path before /usr/bin.InstructionsDefining Ant propertiesThere are a number of ant properties that are used to control the build process of Jikes RVM. These properties may either be specified on the command line by "-Dproperty=variable" or they may be specified in a file named ".ant.properties" in the base directory of the jikesrvm source tree. The ".ant.properties" file is a standard Java property file with each line containing a "property=variable" and comments starting with a # and finishing at the end of the line. The following table describes some properties that are commonly specified.PropertyDescriptionDefaulthost.nameThe name of the host environment used for building Jikes RVM. The host environment defines the paths to the tools used during the build, e.g. the path to the C compiler. The name should match one of the files located in the build/hosts/ directory minus the '.properties' extension.Nonetarget.nameThe name of the target environment for Jikes RVM. The name should match one of the files located in the build/targets/ directory minus the '.properties' extension. This should only be specified when cross compiling the Jikes RVM. See Cross-Platform Building for a detailed description of cross compilation.${host.name}config.nameThe name of the configuration used when building Jikes RVM. The name should match one of the files located in the build/configs/ directory minus the '.properties' extension. This setting is further described in the section Configuring the RVM.Nonepatch.nameAn identifier for the current patch applied to the source tree. See Building Patched Versions for a description of how this fits into the standard usage patterns of Jikes RVM.""components.dirThe directory where Ant looks for external components when building the RVM.${jikesrvm.dir}/componentsdist.dirThe directory where Ant stores the final Jikes RVM runtime.${jikesrvm.dir}/distbuild.dirThe directory where Ant stores the intermediate artifacts generated when building the Jikes RVM.${jikesrvm.dir}/targetprotect.config-filesDefine this property if you do not want the build process to update configuration files when auto downloading components.(Undefined)components.cache.dirThe directory where Ant caches downloaded components.  If you explicitly download a component, place it in this directory.(Undefined, forcing download)require.rvm-unit-testsIf set to true, run unit tests on the built rvm image. Use with care as it will significantly increase build times for configurations that are compiled using a non-optimizing compiler (see below).(Undefined, tests are not run)require.checkstyleOnly useful if you want to contribute changes to the Jikes RVM. If set to true, run checkstyle during the build to check for violations of the Jikes RVM Coding Style and Coding Conventions for assertions.(Undefined, no checks run)At a minimum it is recommended that the user specify the host.name property in the ".ant.properties" file.The configuration files in "build/targets/" and "build/hosts/" are designed to work with a typical install but it may be necessary to overide specific properties. The easiest way to achieve this is to specify the properties to override in the ".ant.properties" file.Selecting a ConfigurationA "configuration" in terms of Jikes RVM is the combination of build time parameters and component selection used for a particular Jikes RVM image. The Configuring the RVM section describes the details of how to define a configuration. Typical configuration names include;production: This configuration defines a fully optimized version of the Jikes RVM.development: This configuration is the same as production but with debug options enabled. The debug options perform internal verification of Jikes RVM which means that it builds and executes more slowly.prototype: This configuration is compiled using an unoptimized compiler and includes minimal components which means it has the fastest build time.prototype-opt: This configuration is compiled using an unoptimized compiler but it includes the adaptive system and optimizing compiler. This configuration has a reasonably fast build time.If a user is working on a particular configuration most of the time they may specify the config.name ant property in ".ant.properties" otherwise it should be passed in on the command line "-Dconfig.name=...".Fetching DependenciesThe Jikes RVM has a build time dependency on the GNU Classpath class library and depending on the configuration may have a dependency on GCSpy. The build system will attempt to download and build these dependencies if they are not present or are the wrong version.To just download and install the GNU Classpath class library you can run the command "ant -f build/components/classpath.xml". After this command has completed running it should have downloaded and built the GNU Classpath class library for the current host. See the Using GCSpy page for directions on building configurations with GCSpy support.If you wish to manually download components (for example you need to define a proxy, so ant is not correctly downloading), you can do so and identify the directory containing the downloads using "-Dcomponents.cache.dir=<download directory>" when you build with ant.Building the RVMThe next step in building Jikes RVM is to run the ant command "ant" or "ant -Dconfig.name=...". This should build a complete RVM runtime in the directory "${dist.dir}/${config.name}_${target.name}". The following table describes some of the ant targets that can be executed. A complete list of documented targets can be listed by executing the command "ant -projecthelp"TargetDescriptioncheck-propertiesCheck that all the required properties are defined.compile-mmtkCompile MMTk toolkit.prepare-sourceGenerate configuration independent source code if required or force.generation property is set.prepare-config-sourceGenerate source code for the current configuration if required or force.generation property is set.main or runtimeBuild a runtime image.cleanRemove the build and image directory for the current configuration.very-cleanAs with clean but also remove Java files generated by scripts.real-cleanAs with very-clean but remove all compiled images.profiled-imageCompile a baseline version of the RVM for profiling then use the profile information to recompile the given config.name image.Running the RVMJikes RVM can be executed in a similar way to most Java Virtual Machines. The difference is that the command is "rvm" and resides in the runtime directory (i.e. "${dist.dir}/${config.name}_${target.name}"). See Running the RVM for a complete list of command line options. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "linked to coding conventions for assertion style example" Regrettably, some code in the current system does not follow any ... [More] consistent coding style. This is an unfortunate residuum of the system's evolution.  To alleviate this problem, we present this style guide for new Java™ code; it's just a small tweak of Sun®'s style guide.  We also use checkstyle to support a gradually expanding subset of these conventions.  The current set of enforced checkstyle rules are defined by $RVM_ROOT/build/checkstyle/rvm-checks.xml and are verified as part of the pre-commit test run. To check for violations of the coding style without running the tests, use buildit or run "ant checkstyle" from the command line.File HeadersEvery file needs to have the license header.A Java example of the notices follows./* * This file is part of the Jikes RVM project (http://jikesrvm.org). * * This file is licensed to You under the Eclipse Public License (EPL); * You may not use this file except in compliance with the License. You * may obtain a copy of the License at * * http://www.opensource.org/licenses/eclipse-1.0.php * * See the COPYRIGHT.txt file distributed with this work for information * regarding copyright ownership. */package org.jikesrvm;import org.jikesrvm.classloader.ClassLoader; // FILL ME IN/** * TODO Substitute a brief description of what this program or library does. */Coding style descriptionThe Jikes™ RVM coding style guidelines are defined with reference to the Sun® Microsystems "Code Conventions for the Java™ Programming Language", with a few exceptions listed below. Most of the style guide is intuitive; however, please read through the document (or at least look at its sample code).We have adopted four modifications to the Sun code conventions:Two-space indenting The Sun coding convention suggests 4 space indenting; however with 80-column lines and four-space indenting, there is very little room left for code. Thus, we recommend using 2 space indenting. There are to be no tabs in the source files or trailing white space on any line.132 column lines in exceptional cases The Sun coding convention is that lines be no longer than 80 columns. Several Jikes RVM contributors have found this constraining. Therefore, we allow 132 column lines for exceptional cases, such as to avoid bad line breaks.if (VM.VerifyAssertions) As a special case, the condition if (VM.VerifyAssertions) is usually immediately followed by the call to VM._assert(), with a single space substituting for the normal newline-and-indentation. See the coding conventions for an example.Capitalized fields Under the Sun coding conventions, and as specified in The Java Language Specification, Second Edition, the names of fields begin with a lowercase letter. (The only exception they give is for some final static constants, which have names ALL_IN_CAPITAL_LETTERS, with underscores separating them.) That convention reserves IdentifiersBeginningWithACapitalLetterFollowedByMixedCase for the names of classes and interfaces. However, most of the final fields in the Configuration class and the Properties interface also are in that format. Since the VM class inherits fields from both Properties and Configuration, that's how we get VM.VerifyAssertions, etc.Javadoc requirementsAll files should contain descriptive comments in Javadoc™ form so that documentation can be generated automatically. Of course, additional non-Javadoc source code comments should appear as appropriate.All classes and methods should have a block comment describing them. JavaDoc comments must not be copied from methods that are being overriden. If the comment from the method that you are overriding is sufficient, you do not need to provide JavaDoc for the newly added method - JavaDoc will automatically copy the JavaDoc from the overriden method. If you want to extend the comment from the overriden method with new information, use {@inheritDoc} to copythe comment from the superclass and add your text.All methods contain a short description of their arguments (using @param), the return value (using @return) and the exceptions they may throw (using @throws).Each class should include @see and @link references as appropriate. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "mentioned IR.PARANOID and IR.SANITY_CHECK" Assertions in Jikes RVM and MMTkPartly for historical reasons, we use our own built-in ... [More] assertion facility rather than the one that appeared in Sun®'s JDK 1.4. All assertion checks have one of the two forms: if (VM.VerifyAssertions) VM._assert(condition) if (VM.VerifyAssertions) VM._assert(condition, message) VM.VerifyAssertions is a public static final field. The config.assertions configuration variable determines VM.VerifyAssertions' value. If config.assertions is set to none, Jikes RVM has no assertion overhead.If you use the form without a message, then the default message "vm internal error at:" will appear.If you use the form with a message the message must be a single string literal. Doing string appends in assertions can be a source of horrible performance problems when assertions are enabled (i.e. most development builds). If you want to provide a more detailed error message when the assertion fails, then you must use the following coding pattern: if (VM.VerifyAssertions && condition) { ... build message ... VM._assert(VM.NOT_REACHED, message); } An assertion failure is always followed by a stack dump.Use VM.ExtremeAssertions instead of VM.VerifyAssertions if the assertion is costly to check but generally useful. These kinds of assertions are only enabled when config.assertions is set to extreme.Use IR.SANITY_CHECK or IR.PARANOID to guard assertions that relate to the intermediate representation in the optimizing compiler.Assertions in the MMTk Test HarnessThe assert keyword may be used in the MMTk Harness. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "mentioned that assert may be used in the MMTk test harness" Assertions in Jikes RVM and MMTkPartly for historical reasons, we use ... [More] our own built-in assertion facility rather than the one that appeared in Sun®'s JDK 1.4. All assertion checks have one of the two forms: if (VM.VerifyAssertions) VM._assert(condition) if (VM.VerifyAssertions) VM._assert(condition, message) VM.VerifyAssertions is a public static final field. The config.assertions configuration variable determines VM.VerifyAssertions' value. If config.assertions is set to none, Jikes RVM has no assertion overhead.If you use the form without a message, then the default message "vm internal error at:" will appear.If you use the form with a message the message must be a single string literal. Doing string appends in assertions can be a source of horrible performance problems when assertions are enabled (i.e. most development builds). If you want to provide a more detailed error message when the assertion fails, then you must use the following coding pattern: if (VM.VerifyAssertions && condition) { ... build message ... VM._assert(VM.NOT_REACHED, message); } An assertion failure is always followed by a stack dump.Use VM.ExtremeAssertions instead of VM.VerifyAssertions if the assertion is costly to check but generally useful. These kinds of assertions are only enabled when config.assertions is set to extreme.Assertions in the MMTk Test HarnessThe assert keyword may be used in the MMTk Harness. View Online · View Changes Online [Less]

Page edited by Robin Garner One of the services that MMTk expects a virtual machine to perform on its behalf is the scanning of objects, i.e. identifying and processing ... [More] the pointer fields of the live objects it encounters during collection. In principle the implementation of this interface is simple, but there are two moderately complex optimizations layered on top of this.From MMTk's point of view, each time an object requires scanning it passes it to the VM, along with a TransitiveClosure object. The VM is expected to identify the pointers and invoke the processEdge method on each of the pointer fields in the object.  The rationale for the current object scanning scheme is presented in this paper.JikesRVM to MMTk InterfaceMMTk requires its host virtual machine to provide an implementation of the class org.mmtk.vm.Scanning as its interface to scanning objects.  JikesRVM's implementation of this class is found under the source tree MMTk/ext/vm/jikesrvm, in the class org.jikesrvm.mm.mmtk.Scanning.  The methods we are interested in are scanObject(TransitiveClosure, ObjectReference) and specializedScanObject(int, TransitiveClosure, ObjectReference).In MMTk, each plan defines one or more TransitiveClosure operations.  Simple full-heap collectors like MarkSweep only define one TransitiveClosure, but complex plans like GenImmix or the RefCount plans define several.  MMTk allows the plan to request specialized scanning on a closure-by-closure basis, closures that are specialized call specializedScanObject while unspecialized ones call scanObject.  Specialization is covered in more detail below.In the absence of hand-inlined scanning, or if specialization is globally disabled, scanning reverts to the fallback method in org.jikesrvm.mm.mminterface.SpecializedScanMethod.  This method can be regarded as the basic underlying mechanism, and is worth understanding in detail. RVMType type = ObjectModel.getObjectType(objectRef.toObject()); int[] offsets = type.getReferenceOffsets(); This code fetches the array of offsets that JikesRVM uses to identify the pointer fields in the object.  This array is constructed by the classloader when a class is resolved. if (offsets != REFARRAY_OFFSET_ARRAY) { for(int i=0; i < offsets.length; i++) { trace.processEdge(objectRef, objectRef.toAddress().plus(offsets[i])); } One distinguished value (actually null) is used to identify arrays of reference objects, and this block of code scans scalar objects by tracing each of the fields at the offsets given by the offset array. } else { for(int i=0; i < ObjectModel.getArrayLength(objectRef.toObject()); i++) { trace.processEdge(objectRef, objectRef.toAddress().plus(i << LOG_BYTES_IN_ADDRESS)); } } The other case is reference arrays, for which we fetch the array length and scan each of the elements.The internals of trace.processEdge vary by collector and by collection type (e.g. nursery/full-heap in a generational collector), and the details need not concern us here.Hand InliningHand inlining was introduced in February 2011, and uses a cute technique to encode 3 bits of metadata into the TIB pointer in an object's header.  The 7 most frequent object patterns are encoded into these bits, and then special-case code is written for each of them.Hand inlining produces an average-case speedup slightly better than specialization, but performs poorly on some benchmarks.  This is why we use it in combination with specialization.Specialized ScanningSpecialized Scanning was introduced in September 2007.  It speeds up GC by removing the process of fetching and interpreting the offset array that describes each object, by jumping directly to a hard-coded method for scanning objects with a particular pattern.The departure point from "standard" java into the specialized scanning method is SpecializedScanMethod.invoke(...), which looks like this @SpecializedMethodInvoke @NoInline public static void invoke(int id, Object object, TransitiveClosure trace) { /* By default we call a non-specialized fallback */ fallback(object, trace); } The @SpecializedMethodInvoke annotation signals to the compiler that it should dispatch to one of the specialized method slots in the TIBCreation of specialized methods is handled by the class org.jikesrvm.classloader.SpecializedMethodManager. View Online · View Changes Online [Less]

Page edited by Robin Garner *** Work in progress ***This page gives a brief outline of the major control flows in the execution of a garbage collector in MMTk.  For ... [More] simplicity, we focus on the MarkSweep collector, although much of the discussion will be relevant to other collectors. This page assumes you have a basic knowledge of garbage collection, for those that don't, please see one of the standard texts such as The Garbage Collection Handbook. Structure of a PlanAn MMTk Plan is required to provide 5 classes.  They are required to have consistent names which start with the same name and have a suffix that indicates which class it inherits from. in the case of the MarkSweep plan, the name is "MS".MS - this is a singleton class that is a subclass of org.mmtk.plan.Plan.   This class encapsulates data structures that are shared among multiple threads.MSMutator - subclass of org.mmtk.plan.MutatorContext.  This class encapsulates data structures that are local to a single mutator thread.  In the case of Jikes RVM, a Thread is actually a subclass of this class for efficiency reasons.MSCollector - subclass of org.mmtk.plan.CollectorContext.  This provides thread-local data structures specific to a garbage collector thread.MSConstraints - subclass of org.mmtk.plan.PlanConstraints.  This provides configuration information that the host virtual machine might need.  It is separated out from the Plan class in order to prevent circular class loading dependencies.MSTraceLocal - subclass of org.mmtk.plan.TraceLocal.  This provides thread-local data structures specific to a particular way of traversing the heap.  In a simple collector like MarkSweep, there is only one of these classes, but in more complex collectors there may be several.  For example, in a generational collector, there will be one TraceLocal class for a nursery collection, and another for a full-heap collection.The basic architecture of MMTk is that virtual address space is divided into chunks (of 4MB in a 32-bit memory model) that are managed according to a specific policy.  A policy is implemented by an instance of the Space class, and it is in the policy class that the mechanics of a particular mechanism (like mark-sweep) is implemented.  The task of a Plan is to create the policy (Space) objects that manage the heap, and to integrate them into the MMTk framework.  MMTk exposes some of this memory management policy to the host VM, by allowing the VM to specify an allocator (represented by a small integer) when allocating space.  The interface exposed to the VM allows it to choose whether an object will move during collection or not, whether the object is large enough to require special handling etc.  The MMTk plan is free (within the semantic guarantees exposed to the VM) to direct each of these allocators to a particular policy.PoliciesA policy describes how a range of virtual address space is managed.  The base class of all policies is org.mmtk.policy.Space, and a particular instance of a policy is known generically as a space.  The static initializer of a Plan and its subclasses define the spaces that make up an MMTk plan.   MS.java public static final MarkSweepSpace msSpace = new MarkSweepSpace("ms", VMRequest.create()); public static final int MARK_SWEEP = msSpace.getDescriptor(); In this code fragment, we see the MS plan defined.  Note that we generally also define a static final space descriptor.  This is an optimization that allows some rapid operations on spaces.A Space is a global object, shared among multiple mutator threads.  Each policy will also have one or more thread-local classes which provide unsynchronized allocation.  These classes are subclasses of org.mmtk.utility.alloc.Allocator, and in the case of MarkSweep, it is called MarkSweepLocal.  Instances of MarkSweepLocal are created as part of a mutator context, like thisMSMutator.java protected MarkSweepLocal ms = new MarkSweepLocal(MS.msSpace); The design pattern is that the local Allocator will allocate space from a thread-local buffer, and when that is exhausted it will allocate a new buffer from the global Space, performing appropriate locking.  The constructor of the MarkSweepLocal specifies the space from which the allocator will allocate global memory.AllocationMMTk provides two methods for allocating an object.  These are provided by the MSMutator class, to give each plan the opportunity to use fast, unsynchronized thread-local allocation before falling back to a slower synchronized slow-path.The version implemented in MarkSweep looks like this:MSMutator.java public Address alloc(int bytes, int align, int offset, int allocator, int site) { if (allocator == MS.ALLOC_DEFAULT) { return ms.alloc(bytes, align, offset); } return super.alloc(bytes, align, offset, allocator, site); } The basic structure of this method is common to all MMTk plans.  First they decide whether the operation applies to this level of abstraction (if (allocator == MS.ALLOC_DEFAULT)), and if so, delegate to the appropriate place, otherwise pass it up the chain to the super-class.  In the case of MarkSweep, MSMutator delegates the allocation to its thread-local MarkSweepLocal object ms.The alloc method of MarkSweepLocal is inherited from SegregatedFreeListLocal (mark-sweep is not the only way of managing free-list allocation), and looks like thisSegregatedFreeListLocal.java (simplified) public final Address alloc(int bytes, int align, int offset) { int sizeClass = getSizeClass(bytes); Address cell = freeList.get(sizeClass); if (!cell.isZero()) { freeList.set(sizeClass, cell.loadAddress()); /* Clear the free list link */ cell.store(Address.zero()); return cell; } return allocSlow(bytes, align, offset); } This is a standard pattern for thread-local allocation: first we look in the thread-local space (line 3), and if successful return the result (lines 4-8).  If unsuccessful, we request space from the global policy via the method Allocator.allocSlow.  This is the common interface that all Allocators use to request space from the global policy.  This will eventually call the allocator-specific allocSlowOnce method.  The workings of the allocSlowOnce method are very policy-specific, so not appropriate to look at at this stage, but eventually all policies will attempt to acquire fresh virtual memory via the Space.acquire method.Space.acquire is the only correct way for a policy to allocate new virtual memory for its own use.  Space.java (simplified) public final Address acquire(int pages) { pr.reservePages(pages); // Poll, either fixing budget or requiring GC if (VM.activePlan.global().poll(false, this)) { VM.collection.blockForGC(); return Address.zero(); // GC required, return failure } // Page budget is ok, try to acquire virtual memory Address rtn = pr.getNewPages(pagesReserved, pages, zeroed); if (rtn.isZero()) { // Failed, so force a GC boolean gcPerformed = VM.activePlan.global().poll(true, this); VM.collection.blockForGC(); return Address.zero(); } return rtn; } The logic of space.acquire is:First, poll the plan to find out whether the heap is full.  This logic is performed by the plan, because it has knowledge of copy reserves etc.The 'poll' method will request a GC if required, and return true if it has done so.Then we wait for GC if required.  'poll' can't wait, because it is called in circumstances that aren't GC safe.If Plan.poll(...) returns false (we are within the allowed heap size), we call pr.getNewPages to allocate virtual memory.  At this stage we can find that we have run out of virtual memory, and if so, we force a GCIf a GC is performed, we return Address.zero(), rather than retrying locally.  In many plans, the next allocation request will be satisfied by re-using space in a page that already belongs to a policy, so the post-GC allocation must be performed further up in the call stack.  The retry logic is handled in Allocator.allocSlowInline. Allocator.java (simplified) public final Address allocSlowInline(int bytes, int alignment, int offset) { boolean emergencyCollection = false; while (true) { Address result = allocSlowOnce(bytes, alignment, offset); if (!result.isZero()) { return result; } if (emergencyCollection) { VM.collection.outOfMemory(); } emergencyCollection = Plan.isEmergencyCollection(); } } This code fragment shows the retry logic in the allocator.  We try allocating using allocSlowOnce, which may recycle partially-used blocks and eventually call Space.acquire.  If a GC occurred, we try again.  Eventually the plan will request an emergency collection which will (for example) cause soft references to be dropped.  If this fails we throw an OutOfMemoryError.CollectionSchedulingIn a stop-the-world garbage collector like MarkSweep, the mutator threads run until memory is exhausted, then all mutator threads are suspended, the collector threads are activated, and they perform a garbage collection.  After the GC is complete, the collector threads are suspended and the mutator threads resume.  MMTk also has some support for concurrent collectors, in which one or more collector threads can be scheduled to run alongside the mutator, either exclusively or in addition to (hopefully briefer) stop-the-world phases. Thread scheduling in MMTk is handled by a GC controller thread, implemented in the singleton class org.mmtk.plan.ControllerCollectorContext  held in the static field Plan.controlCollectorContext. Whenever a collection is initiated, it is done by calling methods on this object.InitiatingAs mentioned above, every attempt to allocate fresh virtual memory calls the current plan's poll(...) method.  This initiates a GC by calling controlCollectorContext.request(), which in a stop-the-world collector like MarkSweep pauses the mutator threads and then wakes the collector threads.  The main loop of the garbage collector is simply the run() method of ParallelCollector, shown below.ParallelCollector public void run() { while(true) { park(); collect(); } } The collect() method is specific to the type of collector, and in StopTheWorldCollector it looks like thisStopTheWorldCollector public void collect() { Phase.beginNewPhaseStack(Phase.scheduleComplex(global().collection)); } Collector PhasesEvery garbage collection consists of a series of steps.  Each step is either executed once (e.g. updating the mark state before marking the heap), or in parallel on all available collector threads (e.g. the parallel mark phase).  The actual work of a step is done by the collectionPhase method of the global, collector or mutator class of a plan.In early versions of MMTk, the main collection method was a template method, calling individual methods for each phase of the collection.  As the number of collectors in MMTk grew, this became unwieldy and has been replaced with a configurable mechanism of phases.  The class org.mmtk.plan.Simple defines the basic structure of most of MMTk's garbage collectors.  First it defines the phases themselves,Simple.java public static final short SET_COLLECTION_KIND = Phase.createSimple("set-collection-kind", null); public static final short INITIATE = Phase.createSimple("initiate", null); public static final short PREPARE = Phase.createSimple("prepare"); ... Each phase of the collection is represented by a 16-bit integer, an index into a table of Phase objects.  Simple phases are scheduled, and combined into sequences, or complex phases.Simple.java /** Ensure stacks are ready to be scanned */ protected static final short prepareStacks = Phase.createComplex("prepare-stacks", null, Phase.scheduleMutator (PREPARE_STACKS), Phase.scheduleGlobal (PREPARE_STACKS)); A simple phase can be scheduled in one of 4 ways: Global.  One collector thread is chosen to run the collectionPhase method of the global Plan object.Collector.  All collector threads run collectionPhase of the plan's CollectorContext object(s).Mutator.  The collector threads run in parallel and iterate over the available MutatorContext objects (ie the mutator threads), and run the mutator's collectionPhase method.  Note that the collector threads are performing work on a per-mutator basis, because in general the mutator threads are stopped at this point.Concurrent.  The controller is requested to start a concurrent collectcor thread.Between every phase of a collection, the collector threads rendezvous at a synchronization barrier.  The actual execution of a collector's phases is done in the method Phase.processPhaseStack.  This method handles resuming a concurrent collection as well as running a full stop-the-world collection.The actual work of a collection phase is done (as mentioned above) in the collectionPhase method of the major Plan classes.MS.java @Inline @Override public void collectionPhase(short phaseId) { if (phaseId == PREPARE) { super.collectionPhase(phaseId); msTrace.prepare(); msSpace.prepare(true); return; } if (phaseId == CLOSURE) { msTrace.prepare(); return; } if (phaseId == RELEASE) { msTrace.release(); msSpace.release(); super.collectionPhase(phaseId); return; } super.collectionPhase(phaseId); } This excerpt shows how the global MS plan implements collectionPhase, illustrating the key phases of a simple stop-the-world collector.  The prepare phase performs tasks such as changing the mark state, the closure phase performs a transifive closure over the heap (the mark phase of a mark-sweep algorithm) and the release phase performs any post-collection steps.  Where possible, a plan is structured so that each layer of inheritance deals only with the objects it creates, i.e. the MS class operates on the msSpace and delegates work on all other spaces to the super-class where they are defined.  By convention the PREPARE phase is performed outside-in (super-class preparation first) and RELEASE is done inside-out (local first, super-class second).Tracing the heapThe main operation of a tracing collector is the transitive closure operation where all (or a subset) of the object graph is visited.  Some collectors such as generational collectors perform these operations in more than one way, e.g. a nursery collection in a generational collector does not trace through pointers into the mature space, while a full-heap collection does.  All MMTk collectors are designed to run using several parallel threads, using data structures that have unsynchronized thread-local and synchronized global components in the same way as MMTk's policy classes.MMTk's trace operation uses the following terminology:An edge is a reference in the heap from one reference field to the object (or node) it points to.Tracing an object is the policy-defined operation performed by the collector on an object.  In a mark-sweep policy this means setting the mark state of the object.  In a copying policy this means moving the object to its new location.Scanning is the process of identifying the reference fields of an object and processing the objects reachable from each of them.Each distinct transitive closure operation is defined as a subclass of TraceLocal.  The closure is performed in the collectionPhase method of the plan-specific CollectorContext classMSCollector.java public void collectionPhase(short phaseId, boolean primary) { ... if (phaseId == MS.CLOSURE) { fullTrace.completeTrace(); return; } ... } The initial starting point for the closure is computed by the STACK_ROOTS and ROOTS phases, which add root locations to a buffer by calling TraceLocal.reportDelayedRootEdge.  The closure operation proceeds by invoking traceObiect on each root location (in method processRootEdge), and then invoking scanObject on each heap object encountered.  Note that the CLOSURE operation is performed multiple times in each GC, due to processing of reference types. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "remove sentence about Swing and AWT being supported by GNU Classpath (coverage is too incomplete at the moment)" This page ... [More] captures work related to the Jikes RVM.Class LibrariesClasspathThe GNU Classpath project is creating an open source replacement to the Java libraries provided by proprietary JVM developers. The Jikes RVM uses the GNU Classpath libraries by default. The Classpath libraries are released under the GPL with exception.OpenJDKThe OpenJDK is the open source JVM and class library from Sun. Previously this code has been closed source, but as of April 2007 this code (except for portions that Sun doesn't own the copyright for) has been released. The OpenJDK uses the GPL with exception, the same as Classpath.Harmony The Apache Harmony project was trying to create a world class, certified implementation of the Java Platform Standard Edition. It has reached its end of life and has been moved to the Apache Attic.The project was creating an open source class library that could be used for closed and open source JVMs. The Apache Harmony project released most code under the Apache License.JVMsNote that almost all JVMs mentioned here are licensed under the GPL. Because the GPL and the EPL are not compatible, code generally cannot be shared between these projects and the Jikes RVM.Maxine Research VMMaxine is a meta-circular JVM with a strong focus an modularity. It is being developed at Oracle Labs. Maxine uses an unmodified standard JDK as its class library and provides its own development tool, the Maxine Inspector.Metacircular Research PlatformThe Metacircular Research Platform is fork of the Jikes RVM and licensed under the EPL.JamVMJamVM is an open source JVM.CACAOThe CACAO JVM is a JVM from the Computer Languages group at the Vienna University of Technology.Jato VMJato is a JIT-only JVM.MoxieMoxie describes itself via the following. "The Moxie project will create an open source platform for developing product-quality JVMs and an environment for JVM innovation. Our goal is to build the most innovation-friendly JVM development platform to date and from it, the most innovative product-quality JVMs. A product-quality JVM has outstanding performance, scalability and reliability. The development philosophy of Moxie is to leverage its openness to draw on the most experienced members of the VM research and development community, from both industry and academia."GCJThe GNU Compiler for Java is an open source Java compiler that statically compiles Java code into native code.KaffeKaffe is an open source JVM.SquawkSquawk is a research virtual machine from Sun where as much of the JVM as possible has been written in Java. It is targetted at small devices.Joeq Joeq is  a JVM implementation using a range of compilers and interpreters. It is written in 100% Java but has the ability to link in native.GC FrameworksGCspyGCspy is a framework for spying on and visualizing the activity of a garbage collector. GCspy is supported by the Jikes RVM and MMTk.MPSThe Memory Pool System Project from Ravenbrook is an open source GC framework.Operating SystemsJNodeJNode is an open source operating system written in Java with a JVM written in Java. Portions of the Jikes RVM have been ported to JNode.JX OSJX OS is an open source Java operating system. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "changed links to MMTk papers (please double-check)" To learn more about the system, you may want to read:Book chaptersThe ... [More] strength of metacircular virtual machines: Jikes RVM, appearing in Beautiful Architecture, January 2009. Chapter by Ian Rogers and David Grove, editors Diomidis Spinellis and Georgios Gousios, O'Reilly publishers.PapersHistorical overview of project (Apr. 2005)Technical summary of the structure of the system (Jan. 2000)Writing in Java (Nov. 1999)MMTk, the memory management system (the listed papers are available via Steve Blackburn's website)modular design and performance impact: Oil and Water? High Performance Garbage Collection in Java with MMTk, ICSE 2004, May 2004performance study: Myths and Realities: The Performance Impact of Garbage Collection, SIGMETRICS — Performance 2004, June 2004Adaptive optimization system (Oct. 2000,Nov. 2004)Porting the system to Linux/IA32 (Aug. 2002)Tutorial slidesMMTk memory management toolkit (Oct. 2004)Optimizing compiler and adaptive system (Nov. 2002)Complete system (Sept. 2001)General field of dynamic compilation and adaptive optimization (June. 2004)User Guide View Online · View Changes Online [Less]

Page edited by Erik Brangs - "changed link for ISMM'04 MMTk tutorial to point to IBM's website" This page contains slides from stand-alone presentations. Some ... [More] of the Publications also have presentations associated with them.Jikes RVMAuthor: Ian RogersConference: Free and Open Source Developers' European MeetingAbstract:A short presentation on the Jikes RVM and related research in the context of open source Java.Download: PowerPoint (5.8MB)Dynamic Compilation and Adaptive Optimization in Virtual MachinesAuthors: ''Matthew Arnold, Stephen Fink, David Grove, and Michael Hind''Instructor: Michael HindConference: ACACES'06, July 24-28, 2006 (This is an updated version of the PLDI'04 tutorial)Abstract:The past decade has witnessed the widespread adoption of programming languages designed to execute on virtual machines, such as the Java and C# programming language. However, such languages face significant performance challenges beyond those confronted by traditional languages. First, portable program representations and dynamic language features, force the deferral of most optimizations until runtime, inducing runtime optimization overhead. Second, modular program representations preclude many forms of whole-program inter-procedural optimization. Third, virtual machines incur additional costs for runtime services such as security guarantees and automatic memory management. To address these challenges, mainstream virtual machine implementations include substantial infrastructure for online profiling, dynamic compilation, and feedback-directed optimization. As a result, adaptive optimization has begun to mature as a widespread production-level technology.This course will survey the state-of-the-art in the areas of dynamic compilation and adaptive optimization in virtual machines. Dynamic compilation is the process of dynamically optimizing a portable representation, such as Java byte codes, into native code. Adaptive optimization is the online decision process that determines the overall strategy for profiling and employing dynamic compilation. In addition to surveying the state-of-the-art, and highlighting the many topics for open research in this area, this course will also debunk several misconceptions about these two topics, such asDynamic compilers must be blazingly fast.Dynamic class loading is a fundamental roadblock to cross-method optimization.A static compiler can always get better performance than a dynamic compiler.Sophisticated profiling is too expensive to perform online.Program optimization is a dead field.Lack of a suitable infrastructure is a significant barrier to research in this area.Download: PDF (3.3MB)MMTk: The Memory Management ToolkitPresentors: ''Steve Blackburn and Perry Cheng''Conference: ISMM'04, October 23, 2004 (ISMM'04 Tutorial)Abstract: MMTk is a framework for construction of garbage collectors within the open-source Jikes Research Virtual Machine. The tutorial was given by two of its creators.Download: PDF (325KB)Jikes RVM Optimizing Compiler Intermediate Code RepresentationPresentors: Shane BrewerEvent: Group presentation at University of Alberta, March 20, 2003.Download: PowerPoint (280K) or PDF (247K)The Design and Implementation of the Jikes RVM Optmizing CompilerPresentors: ''David Grove and Michael Hind''Conference: OOPSLA '02, November 5, 2002 (OOPSLA '02 Tutorial)Abstract:The Jikes Research Virtual Machine (RVM) is a software infrastructure designed to execute Java programs typically used in programming language implementation research. The Jikes RVM is available as an open source project. The Jikes RVM provides the academic and research communities with a flexible open testbed to prototype new virtual machine technologies and experiment with various design alternatives. A large number of academic research groups have already adopted it. It runs on AIX, Linux, and OS X platforms and demonstrates industrial strength performance for many benchmark programs. The Jikes RVM includes state-of-the-art technologies for dynamic compilation, adaptive optimization, garbage collection, thread scheduling, and synchronization.This tutorial presents an overview of the Jikes RVM optimizing compiler. The first part of the tutorial covers the structure of the compiler, focusing on the requirements, goals, and design of its intermediate representation (IR). The second part of the tutorial covers some of the compiler's extensive set of analyses and optimizations, ranging from simple local analyzes to SSA-based flow-sensitive optimizations with type-based heap analysis. The last part covers the integration of the optimizing compiler into the adaptive optimization system, focusing on instrumentation compilation and feedback-directed optimizations.Specific issues to be covered include: optimizing the memory model, precise exceptions, and dynamic class loading; compiler requirements for runtime support of garbage collection maps, scheduling (yield points), exception tables, line number information; compiler/runtime system cooperation for fast object allocation and runtime services (for example dynamic type checking or invokeinterface); compiler structure for multiple platforms; tracing an interesting method (for example, one of our enumeration loops from the compiler) through key optimizations to illustrate how type analysis, inlining, scalar replacement, plus a set of traditional optimizations work together; etc.Download: PDF (4,250KB)The Design and Implementation of the Jikes RVM Optmizing CompilerPresentors: ''Stephen Fink and Michael Hind''Conference: PLDI '02, June 16, 2002 (PLDI '02 Tutorial)Abstract:The Jikes Research Virtual Machine (RVM) is a software infrastructure designed to execute Java programs typically used in programming language implementation research. The system runs on the AIX™/PowerPC™ Linux ®/PowerPC, and Linux/IA-32 platforms and demonstrates industrial strength performance for many benchmark programs. Many academic groups have adopted the Jikes RVM as their primary research infrastructure, resulting in publications in leading conferences such as PLDI '02 and ISMM '02. In the first six months since its open source release the VM has been downloaded by over 1000 different IP addresses, including over 70 universities around the world.This two-hour tutorial presents an overview of the Jikes RVM optimizing compiler. The first part of the tutorial covers the structure of the compiler, focusing on the requirements, goals, and design of its intermediate representation (IR). The second part of the tutorial covers some of the compiler's extensive set of analyses and optimizations, ranging from simple local analyses to SSA-based flow-sensitive optimizations with type-based heap analysis. Time permitting, we will highlight the integration of the optimizing compiler into the adaptive optimization system.Download: gzip-compressed PostScript (1,055 KB)The Design and Implementation of the Jalapeño Research VM for JavaPresentors: ''Dick Attanasio and Michael Hind''Conference: International Conference on Parallel Architectures and Compilation Techniques, September 9, 2001 (PACT01 Tutorial)Abstract:The design and implementation of a high-performing Java virtual machine is a formidable task. Over the past three years IBM researchers have developed the Jalapeno research virtual machine for Java as a high-performing server platform. To address the requirements of servers, performance and scalability in particular, Jalapeño was designed from scratch to be as self-sufficient as possible.Key design features of Jalapeño includethe entire VM is implemented in the Java programming language,a flexible online adaptive optimization infrastructure, implemented as concurrent Java threads, utilizes two compilers and no interpreter guided by a cost-benefit modela family of parallel, type-exact garbage collectors,a lightweight thread package with compiler-supported preemption, andan aggressive optimizing compiler with multiplel optimization levels.This full-day tutorial will share the lessons learned from the design and implementation of Jalapeño. Design decisions will be contrasted to other Java implementations.Download:All 12 sections (ZIP-compressed PostScript) (2,319K)Individual sections, all in gzip-compressed PostScript:1. Introduction (92K)2. VM (86K) ''Corresponding papers in IBM Systems Journal and OOPSLA '99''3. Exception handling (51K)4. Dynamic Type Checking (126K) ''Corresponding paper in JVM '01''5. Interface invocation (216K) ''Corresponding paper in OOPSLA '01''6. Threading and Synchronization (35K) ''Corresponding paper in IBM Systems Journal''7. JNI support (58K)8. Memory Management (126K) ''Corresponding paper in LCPC '01''9. Optimizing Compiler Overview (240K) ''Corresponding paper in Java&#153 Grande '99''10. Adaptive Optimization System (540K) ''Corresponding paper in OOPSLA '00''11. DejaVu (6817K)12. References (86K)Optimizing Compilation of Java Programs(Revised version of PLDI tutorial)Presentor: ''Vivek Sarkar''Conference: ACM Java Grande, June 2001 (Java Grande Tutorial)Download: gzip-compressed PostScript 186KOptimizing Compilation of Java ProgramsPresentor: ''Vivek Sarkar''Conference: ACM Conference on Programming Languages Design and Implementation, June 2000Download: gzip-compressed PostScript 258KIssues in High-Performance Programming in JavaAuthors: ''Bowen Alpern and Susan Flynn-Hummel''Conference: High Performance Computing System, June 13th, 1999 (HPCS '99 Tutorial)Abstract:Java is a modern object-oriented type-safe programming language with automatic memory management. These features make it attractive to anyone responsible for developing and maintaining a large software project. Its multithreading support is a further inducement to those anxious to exploit parallel processing hardware. To date, however, there has been a performance penulty for using the language. For the vast majority of programming efforts, this is marginal concern at most. But, for performance programming, any degradation in performance is a potential show stopper.Java performance has improved markedly in the last year or two. The advent of a second generation of Just-In-Time (JIT) compiler technology promises to further close the performance gap between Java and traditional languages for most applications. This raises the question: will Java ever be the language of choice for performance-critical applications?Unfortunately, the jury is still out. The Java Grande forum has been established to address the problems with using Java for computationally intensive science and engineering applications. Under its auspices, a number of interesting projects are underway. Proposals for improving Java performance run a bewildering gamut from idioms to be used by the programmer, through bytecode and JIT optimization techniques, to major language changes.This tutorial will systematically identify and classify the aspects of Java that are problematic from the performance point of view. It will then chart the terrain upon which such issues might be addressed. Finally, it will survey approaches to improving Java performance.Download: PostScript file Part 1 (764K), Part 2 (656K)Link to: presentation (html) View Online · View Changes Online [Less]