JikesRVM

Page edited by Erik Brangs - "added Quentin Sabah (for RVM-1047)" Jikes RVM TeamThe Jikes RVM team is responsible for creating or applying the improvements ... [More] that go into the releases of Jikes RVM. The current team is:Steve Blackburn, Australian National University, (Jikes RVM steering committee)Michael Bond, Ohio State UniversityErik BrangsRobin Garner, Australian National UniversityDavid Grove, IBM Research, (Jikes RVM steering committee)Andrew John Hughes, Red HatJ. Eliot B. Moss, University of MassachusettsPast Jikes RVM Team MembersThe following people have greatly contributed to the success of the Jikes RVM project by having served as Jikes RVM team members:Steve AugartPerry Cheng, IBM ResearchJulian Dolby, IBM ResearchPeter Donald, La Trobe UniversityStephen Fink, IBM ResearchDaniel Frampton, Australian National UniversityMatthias Hauswirth, University of Colorado at BoulderMichael Hind, IBM ResearchChris Hoffmann, University of MassachussettsFilip Pizlo, Purdue UniversityFeng Qian, McGill UniversityIan Rogers, University of ManchesterPeter F. Sweeney, IBM ResearchKris Venstermans, University of GhentContributions From Jikes RVM CommunityThe Jikes RVM project sincerely thanks the following people who have made contributions to the system:Eddie AftandilianSteven AugartMichael BaerJames BornholtGreg BorotaErik BrangsShane BrewerBrian D. CarlstromPeter DonaldPhilippe FaesDa FengChapman FlackDaniel FramptonRobin GarnerGeorgios GousiosAndrew GrayJungwoo HaMatthias HauswirthLaurence HellyerMatthew HertzMark HindessChris HoffmannKenneth HosteXianglong HuangRichard JonesGarrett KolpinChristos-Efthymois KotselidisSergiy KyrylkovAlan LawrenceKien LeHan LeeJohn LeunerLukas LoehrerDmitri MakarovAvery MoonJ. Eliot B. MossElias NaurAnders Biehl NorgaardJeff PalmTuan PhanFilip PizloKathiravelu PradeebanCarl RitsonQuentin SabahJoão Reys SantosAndreas SeweRifat ShahriyarAleksey ShipilevJeremy SingerStephen SmaldoneSunil SomanDarko StefanovicSuryia SubramanianTom VanDrunenIan WarringtonMark WielaardXi YangYuval YaromLingli ZhangJisheng ZhaoLei ZhaoSoftware Used by Jikes RVMJikes RVM uses either the class libraries produced by the GNU Classpath project or Apache Harmony.Thanks to David R. Hanson,Christoper W. Fraser, and Todd Proebsting for making available the iburg tool, which we've enhanced for use in Jikes RVM.Thanks to Codehaus and Sourceforge for providing hosting services.The Jalapeño Research ProjectJikes RVM was independently developed as part of the Jalapeño research project at the IBM T.J. Watson Research Center. The following IBM Research employees, academic visitors, and student co-ops contributed to the early releases of Jikes RVM:Bowen AlpernAnthony CocchiHan LeeJanice ShepherdMatthew ArnoldJulian DolbyDerek LieberManu SridharanDick AttanasioTracy FergusonMark MergenPeter F. SweeneyDavid BaconStephen FinkTon NgoMartin TrappJohn J. BartonEugene GluzbergJeff PalmKris VenstermansSteve BlackburnDavid GroveIgor PechtchanskiJohn WhaleyRastislav BodikMichael HindVivek SarkarMaria ButricoDave HovemeyerMauricio SerranoPerry ChengSusan HummelArvin ShepherdJong-Deok ChoiSergiy KyrylkovStephen Smith View Online · View Changes Online [Less]

Page edited by Robin Garner The garbage collectors for Jikes RVM are provided by MMTk. The MMTk: The Memory Manager Toolkit describes MMTk and gives a tutorial on how to ... [More] use and edit it and is the best place to start.  An updated version of the tutorial is here. A detailed description of the call chain from the compilers through to MMTk here is another good place to start understanding how MMTk integrates with JikesRVM.  Anatomy of a Garbage Collector describes the major building blocks of an MMTk collector and Scanning Objects in JikesRVM describes how objects are scanned for their pointer fields during GC.  MMTk also has a pure Java test harness that allows development of garbage collectors in an IDE like eclipse.The RVM can be configured to employ various different allocation managers taken from the MMTk memory management toolkit. Managers divide the available space up as they see fit. However, they normally subdivide the available address range to provide:a metadata area which enables the manager to track the status of allocated and unallocated storage in the rest of the heap.an immortal data area used to service allocations of objects which are expected to persist across the whole lifetime of the RVM runtime.a large object space used to service allocations of objects which are larger than some specified size (e.g. a virtual memory page) - the large object space may employ a different allocation and reclamation strategy to that used for other objects.a small object allocation area which may be divided into e.g.two semi spaces, a nursery space and a mature space, a set of generations, a non-relocatable buddy hierarchy etc depending upon the allocation and reclamation strategy employed by the memory manager.Virtual memory pages are lazily mapped into the RVM's memory image as they are needed.The main class which is used to interface to the memory manager is called Plan. Each flavor of the manager is implemented by substituting a different implementation of this class. Most plans inherit from class StopTheWorldGC which ensures that all active mutator threads (i.e. ones which do not perform the job of reclaiming storage) are suspended before reclamation is commenced. The argument passed to -X:processors determines the number of parallel collector threads that will be used for collection.Generational collectors employ a plan which inherits from class Generational Inter alia, this class ensures that a write barrier is employed so that updates from old to new spaces are detected.Jikes RVM may also use the GCSpy visualization framework. GCSpy allows developers to observe the behavior of the heap and related data structures. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "added some guidelines for communication on the mailing list" The main form of communication for the Jikes RVM project is through ... [More] mailing lists. The following table contains the mailing lists established for this project.List NameDescriptionSubscribeUnsubscribeArchivejikesrvm-announceLow volume list for AnnouncementsSubscribeUnsubscribeArchivejikesrvm-researchersGeneral discussion of Jikes RVM (including design, implementation, issues, and plans).Questions on this list are answered by users of Jikes RVM and core team members.SubscribeUnsubscribeArchivejikesrvm-coreDiscussion of day-to-day development and design among Jikes RVM core team membersSubscribeUnsubscribeArchivejikesrvm-commitsNotification list for changes to the Mercurial repositoriesSubscribeUnsubscribeArchivejikesrvm-regressionAutomatic mail messages and subsequent discussion of nightly regression runsSubscribeUnsubscribeArchivejikesrvm-issuesAutomatic mail messages generated by the Issue Tracking softwareSubscribeUnsubscribeArchiveGuidelinesIf you are not sure which mailing list is the right one, use jikesrvm-researchers.Please introduce yourself when posting for the first time. You should also state your affiliation (e.g. your university) if it's not obvious from your email address.If you are new to the Jikes RVM and have a question about modifying the Jikes RVM, please tell us what hat you want to do (i.e. your goal) before stating your concrete problem. This will give the list members enough context to suggest different approaches.  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 - "removed DaCapo 9.12 from goals and added a benchmark section to project status" General project statusJikes RVM is currently the ... [More] most popular platform for virtual 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?)Detailed 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 Robin Garner The garbage collectors for Jikes RVM are provided by MMTk. The MMTk: The Memory Manager Toolkit describes MMTk and gives a tutorial on how to ... [More] use and edit it and is the best place to start.  An updated version of the tutorial is here. A detailed description of the call chain from the compilers through to MMTk here is another good place to start understanding how MMTk integrates with JikesRVM.  Anatomy of a Garbage Collector describes the major building blocks of an MMTk collector and Scanning Objects in JikesRVM describes how objects are scanned for their pointer fields during GC.The RVM can be configured to employ various different allocation managers taken from the MMTk memory management toolkit. Managers divide the available space up as they see fit. However, they normally subdivide the available address range to provide:a metadata area which enables the manager to track the status of allocated and unallocated storage in the rest of the heap.an immortal data area used to service allocations of objects which are expected to persist across the whole lifetime of the RVM runtime.a large object space used to service allocations of objects which are larger than some specified size (e.g. a virtual memory page) - the large object space may employ a different allocation and reclamation strategy to that used for other objects.a small object allocation area which may be divided into e.g.two semi spaces, a nursery space and a mature space, a set of generations, a non-relocatable buddy hierarchy etc depending upon the allocation and reclamation strategy employed by the memory manager.Virtual memory pages are lazily mapped into the RVM's memory image as they are needed.The main class which is used to interface to the memory manager is called Plan. Each flavor of the manager is implemented by substituting a different implementation of this class. Most plans inherit from class StopTheWorldGC which ensures that all active mutator threads (i.e. ones which do not perform the job of reclaiming storage) are suspended before reclamation is commenced. The argument passed to -X:processors determines the number of parallel collector threads that will be used for collection.Generational collectors employ a plan which inherits from class Generational Inter alia, this class ensures that a write barrier is employed so that updates from old to new spaces are detected.The RVM does not currently support concurrent garbage collection.Jikes RVM may also use the GCSpy visualization framework. GCSpy allows developers to observe the behavior of the heap and related data structures. View Online · View Changes Online [Less]

Page edited by Robin Garner OverviewThe MMTk harness is a debugging tool. It allows you to run MMTk with a simple client - a simple Java-like scripting language - which ... [More] can explicitly allocate objects, create and delete references, etc. This allows MMTk to be run and debugged stand-alone, without the entire VM, greatly simplifying initial debugging and reducing the edit-debug turnaround time. This is all accessible through the command line or an IDE such as eclipse.Running the test harnessThe harness can be run standalone or via Eclipse (or other IDE).Standalone ant mmtk-harness java -jar target/mmtk/mmtk-harness.jar <script-file> [options...] There is a collection of sample scripts in the MMTk/harness/test-scripts directory.  There is a simple wrapper script that runs all the available scripts against all the collectors, bin/test-mmtk [options...]  This script prints a PASS/FAIL line as it goes, and puts detailed output in results/mmtk.In Eclipse bin/buildit localhost --mmtk-eclipse Or in versions before 3.1.1 ant mmtk-harness && ant mmtk-harness-eclipse-project Refresh the project (or import it into eclipse), and then run 'Project > Clean'.Define a new run configuration with main class org.mmtk.harness.Main.Click Run (actually the down-arrow next to the the green button), choose 'Run Configurations...'  Select "Java Application" from the left-hand panel, and click the "new" icon (top left).Fill out the Main tab as belowFill out the Arguments tab as below  The harness makes extensive use of the java 'assert' keyword, so you should run the harness with '-ea' in the VM options.Click 'Apply' and then 'Run' to test the configuration.  Eclipse will prompt for a value for the 'script' variable - enter the name of one of the available test scripts, such as 'Lists', and click OK.  The scripts provided with MMTk are in the directory MMTk/harness/test-scripts.You can configure eclipse to display vmmagic values (Address/ObjectReference/etc) using their toString method through the Eclipse -> Preferences... -> Java -> Debug -> Detail Formatters menu. The simplest option is to check the box to use toString 'As the label for all variables'.Test harness optionsOptions are passed to the test harness as 'keyword=value' pairs.  The standard MMTk options that are available through JikesRVM are accepted (leave off the "-X:gc:"), as well as the following harness-specific options:OptionMeaningplanThe MMTk plan class.  Defaults to org.mmtk.plan.marksweep.MScollectorsThe number of concurrent collector threads (default: 1)initHeapInitial heap size.  It is also a good idea to use 'variableSizeHeap=false', since the heap growth manager uses elapsed time to make its decisions, and time is seriously dilated by the MMTk Harness.maxHeapMaximum heap size (default: 64 pages)traceDebugging messages from the MMTk Harness.  Useful trace options includeALLOC - trace object allocationAVBYTE - Mutations of the 'available byte' in each object headerCOLLECT - Detailed information during GCHASH - Hash code operationsMEMORY - page-level memory operations (map, unmap, zero)OBJECT - trace object mutation events REFERENCES - Reference type processingREMSET - Remembered set processingSANITY - Gives detailed information during Harness sanity checkingTRACEOBJECT - Traces every call to traceObject during GC (requires MMTk support) See the class org.mmtk.harness.lang.Trace for more details and trace options - most of the remaining options are only of interest to maintainers of the Harness itself.watchAddressSet a watchpoint on a given address or comma-separated list of addresses.  The harness will display every load and store to that address.watchObjectWatch modifications to a given object or comma-separated list of objects, identified by object ID (sequence number).gcEveryForce frequent GCs.  Options areALLOC - GC after every object allocation SAFEPOINT - GC at every GC safepointschedulerOptionally use the deterministic scheduler.  Options areJAVA (default) - Threads in the script are Java threads, scheduled by the host JVMDETERMINISTIC - Threads are scheduled deterministically, with yield points at every memory access.schedulerPolicySelect from several scheduling policies,FIXED - Threads yield every 'nth' yield pointRANDOM - Threads yield according to a pseudo-random policyNEVER - Threads only yield at mandatory yieldpointsyieldIntervalFor the FIXED scheduling policy, the yield frequency.randomPolicyLength randomPolicySeed randomPolicyMin randomPolicyMaxParameters for the RANDOM scheduler policy.  Whenever a thread is created, the scheduler fixes a yield pattern of 'length' integers between 'min' and 'max'.  These numbers are used as yield intervals in a circular manner.policyStatsDump statistics for the deterministic scheduler's yield policy.bits=32|64Select between 32 and 64-bit memory models.dumpPcodeDump the pseudo-code generated by the harness interpretertimeoutAbort collection if a GC takes longer than this value (seconds).  Defaults to 30. ScriptsThe MMTk/harness/test-scripts directory contains several test scripts.ScriptPurposeDescriptionAlignmentTest allocator alignment behaviourTests alignment by creating a list of objects aligned to a mixture of 4-byte and 8-byte boundaries.CyclicGarbageTest cycle detector in Reference Counting collectorsCreates large amounts of cyclic garbage in the form of circular linked lists.FixedLiveGeneral collection testHarness version of the FixedLive GC micro-benchmark.  Creates a binary tree, then allocates short-lived objects to force garbage collections.HashCodeHash code test.Creates objects and verifies that their hashcode is unchanged after a GC.LargeObjectLarge object allocator testCreates objects with sizes ranging from 2 to 32 pages (8k to 128k bytes).ListsGenerational collector stress testCreates a set of lists of varying lengths, and then allocates to force collections.  Ensures that there are Mature->Nursery, Nursery->Mature and Stack->Nursery and Stack->Mature pointers at every GC.  Remsets get a serious workout.OutOfMemoryTests out-of-memory handling.Allocates a linked list that grows until the heap fills up.QuicksortGeneral collection testImplements a list-based quicksort. ReferenceTypesReference type testCreates Weak references, forces collections and ensures that they are correctly handled.SpawnConcurrency testCreates lots of threads which allocate objects.SpreadAllocFree-list allocator testCreates large numbers of objects with random size distributions, keeping a fraction of the objects alive.SpreadAlloc16Concurrent free-list allocator testA multithreaded version of SpreadAlloc.Scripting languageBasicsThe language has three types: integer, object and user-defined. The object type behaves essentially like a double array of pointers and integers (odd, I know, but the scripting language is basically concerned with filling up the heap with objects of a certain size and reachability).  User-defined types are like Java objects without methods, 'C' structs, Pascal record types etc.Objects and user-defined types are allocated with the 'alloc' statement: alloc(p,n,align) allocates an object with 'p' pointers, 'n' integers and the given alignment; alloc(type) allocates an object of the given type.  Variables are declared 'c' style, and are optionally initialized at declaration. User-defined types are declared as follows: type list {   int value;   list next; } and fields are accessed using java-style "dot" notation, eg   list l = alloc(list);   l.value = 0;   l.next = null; At this stage, fields can only be dereferenced to one level, eg 'l.next.next' is not valid syntax - you need to introduce a temporary variable to achieve this.Object fields are referenced using syntax like "tmp.int[5]" or "tmp.object[i*3]", ie like a struct of arrays of the appropriate types.Syntax  script ::= (method|type)... method ::= ident "(" { type ident { "," type ident}... ")" ( "{" statement... "}" | "intrinsic" "class" name "method" name "signature" "(" java-class {, java class} ")" type ::= "type" ident "{" field... "}" field ::= type ident ";" statement ::= "if" "(" expr ")" block { "elif" "(" expr ")" block } [ "else" block ] | "while "(" expr ")" block | [ [ type ] ident "=" ] "alloc" "(" expr "," expr [ "," expr ] ")" ";" | [ ident "=" ] "hash" "(" expr ")" ";" | "gc" "(" ")" | "spawn" "(" ident [ "," expr ]... ")" ";" | type ident [ "=" expr ] ";" | lvalue "=" expr ";" lvalue ::= ident "=" expr ";" | ident "." type "[" expr "]" type ::= "int" | "object" | ident expr ::= expr binop expr | unop expr | "(" expr ")" | ident | ident "." type "[" expr "]" | ident "." ident | int-const | intrinsic intrinsic ::= "alloc" ( "(" expr "," expr ["," expr] ") | type ) | "(" expr ")" | "gc " "(" ")" binop ::= "+" | "-" | "*" | "/" | "%" | "&&" | "||" | "==" | "!=" unop ::= "!" | "-" MMTk Unit TestsThere is a small set of unit tests available for MMTk, using the harness as scaffolding.  These tests can be run in the standard test infrastructure using the 'mmtk-unit-tests' test set, or the shell script 'bin/unit-test-mmtk'.  Possibly more usefully, they can be run from Eclipse.To run the unit tests in Eclipse, build the mmtk harness project (see above), and add the directory testing/tests/mmtk/src to your build path (navigate to the directory in the package explorer pane in eclipse, right-click>build-path>Use as Source Folder).  Either open one of the test classes, or highlight it in the package explorer and press the 'run' button. View Online · View Changes Online [Less]

Page edited by Robin Garner Getting MMTk and Jikes RVM and Eclipse working.Download Jikes RVM version 3.0.2 or later (or use hg tip)Ensure you can Build and Run the ... [More] RVM.Ensure you can build and run the BaseBaseNoGC configuration (build with: bin/buildit localhost BaseBaseNoGC, run with something like: dist/BaseBaseNoGC_ia32-linux/rvm HelloWorld Note that this configuration does not perform garbage collection so can only run small benchmarks which do not exhaust available memory. This configuration will be used as the basis for the tutorial.Ensure that your source is successfully imported (and editable) within an IDE such as Eclipse.Set up an Eclipse Run configuration for the NoGC plan using the MMTk Test Harness.Creating The Base Tutorial CollectorCopy the org.mmtk.plan.nogc package to org.mmtk.plan.tutorial (copy and paste the package in Eclipse).Rename the constituent classes from NoGC* to Tutorial* (use Refactor->Rename on each class within the org.mmtk.plan.tutorial package in Eclipse).Edit file class org.mmtk.harness.PlanSpecificConfig, and add the following lines   register(new PlanSpecific("org.mmtk.plan.tutorial.Tutorial"), "Tutorial"); to the static initializer (look for "NoGC").Modify your MMTk Harness Eclipse Run Configuration to use the new Plan (the name of the plan is the second parameter to the "register" method you inserted above), and click 'Run' to run it.Create a new configuration file, build/configs/BaseBaseTutorial.properties, with a single line: config.mmtk.plan=org.mmtk.plan.tutorial.TutorialBuild and run the resulting collector:build with something like: bin/buildit localhost BaseBaseTutorial run with something like: dist/BaseBaseTutorial_ia32-linux/rvm HelloWorld CheckpointThis zip file captures all of the above steps with respect to Jikes RVM 3.0.2. You can use the files within the archive to verify you've completed the above steps correctly. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "direct new users to jikesrvm-researchers" The main form of communication for the Jikes RVM project is through mailing lists. The ... [More] following table contains the mailing lists established for this project.List NameDescriptionSubscribeUnsubscribeArchivejikesrvm-announceLow volume list for AnnouncementsSubscribeUnsubscribeArchivejikesrvm-researchersGeneral discussion of Jikes RVM (including design, implementation, issues, and plans).Questions on this list are answered by users of Jikes RVM and core team members.SubscribeUnsubscribeArchivejikesrvm-coreDiscussion of day-to-day development and design among Jikes RVM core team membersSubscribeUnsubscribeArchivejikesrvm-commitsNotification list for changes to the Mercurial repositoriesSubscribeUnsubscribeArchivejikesrvm-regressionAutomatic mail messages and subsequent discussion of nightly regression runsSubscribeUnsubscribeArchivejikesrvm-issuesAutomatic mail messages generated by the Issue Tracking softwareSubscribeUnsubscribeArchiveWhen in doubt, use jikesrvm-researchers. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "added more hints for contributing code" Contributing DocumentationIf you want to help us improve our User Guide and other online ... [More] documentation, please contact a Steering Committee Member and ask for editing permissions for our wiki space.Contributing CodeIf you have extended Jikes RVM and would like to contribute your extension back to the community, please use the patch tracker to submit your contribution. Please include the following:Your contribution in the form of patches or bundles (see below)The appropriate Statement of Origin (see below)A description of the functionality you are contributingThe version of Jikes RVM used to create your patchYour contribution will be licensed under the EPL (Eclipse Public License), the license used for Jikes RVM. The license has been approved by the OSI (Open Source Initiative) as a fully certified open source license. If your contribution is included in the system, you will be acknowledged on the contributors web page, along with getting the satisfaction of making the world a better place.At minimum, you must do the following before submitting your code contribution:Make sure that your contribution follows our coding style. Use Checkstyle (e.g. via "ant checkstyle") to check for common errors.After verifying that there are no checkstyle errors, run the pre-commit tests on your machine.After the pre-commit run is done, you can find the report at results/tests/pre-commit/Report.html. It should read something like "Total Success Rate: 128/128" (numbers from August 2012). The report will also display the revision number, if applicable. If the revision number ends with a +, you have uncommited changes in your working copy. Check that the uncommited changes are not supposed to be in your patch.The Jikes RVM team will check for those points. You will make it easier to merge your contribution if you ensure that there are no problems in that regard.You can do the following things to increase the chances that your contribution will be merged:Split your contribution in a set of patches with each patch representing a commit. The size of the patches is not important. However, it is important that each patch contains exactly one conceptual change. One way to check this is to think of a summary message for each patch. If your summary message contains an "and", you should check if there is a sensible way to split up your patch. The set of patches should show the development of the feature as it would have been ideally, i.e. you should remove dead ends. Put the reasoning for the changes (and why alternative solutions are not appropriate) in the commit messages. The Linux Foundation has a good article on patch preparation for the Linux kernel (many of the guidelines also apply to contributions for Jikes RVM).Write useful commit messages. Use the first sentence to give a summary of the issue. If you are fixing a JIRA issue, please mention it in the description.Example commit messageRVM-XXXX : Fixed a bug in foo.Longer description of the change, the reasons for the change and the consequences. This part can span multiple paragraphs and is optional: you will need to decide what's important for people looking at the commit.Consider providing a README if your chosen patch format does not support commit messages.Run appropriate existing tests other than pre-commit. This is especially useful if your changes touch an area of the code that is not covered by pre-commit (e.g. alternative garbage collectors).Provide automated tests for your contribution.Follow up on your patch until it is in the mainline. This may include answering questions, reworking your patch and gently reminding the developers of your contribution.Contributing patchesPatches should apply against a revision of the main repository. This ensures that your patch can always be applied easily. You can use hg export to create patch files from your commits.Contributing bundlesIf you contribute your changes in the form of mercurial bundles, you must make sure that the parent changeset of your first changeset is in the main repository. If it is not, hg unbundle will fail and your bundles cannot be imported.Statement of originAll contributions must include one of the Statements of Origin below. Insert your name(s) in the first blank(s) and a high-level summary in the blank in a (i) . Examples of a high-level summary are "Fixed bug in scheduler", "Extended type propagation in optimizing compiler", or "Added new garbage collector".If your contribution is owned by your employer, someone authorized by your employer to make such a decision must add a comment to the patch in the tracker stating that you have permission to contribute it.Statement of Origin: Single Contributor Single Contributor for all Contributions Multiple Contributors View Online · View Changes Online [Less]