JikesRVM

Page edited by Erik Brangs - "mentioned that we do not have tasks for "classical" non-coding activities like translation" The Jikes RVM project aims to provide ... [More] a high-quality state-of-the-art open-source infrastructure for programming language research. Of course, this requires a significant investment in system maintenance and enhancement, to keep the system running on new environments and to keep up with the latest innovations in language design and implementation practice.Feedback and contributions from the research community are the indispensable, invaluable resource that will ensure the project's continued success. Please help to improve some aspect of the system; no improvement is too small or too simple! The more volunteers can contribute, the better the system will serve the research community, resulting in faster and more solid research results. It is also a great help to the community if you contribute your code to the research archive.How can you help Jikes RVM?Jikes RVM is a fairly large, complex, and perhaps intimidating system. However, there are many to-do items which don't require extensive Jikes RVM expertise.This page highlights a selection of low-hanging fruit for potential contributions. This list is of course nowhere near comprehensive, but exists just as a sampling of potential activities.Note that most of the tasks on this page are related to code in some way or another: we currently do not have any tasks for people interested in marketing, translations or graphic design. If you think that the project would benefit from a contribution in this area (or any other area that is not named here), do not hesitate to contact us on the mailing lists.Additional ideas that require code contributions are listed on a separate page.All contributions to Jikes RVM are managed in our JIRA-based issue tracker.Please let us know if the list below is out-of-date by entering a bug against the website.Some low-hanging fruit in no particular orderContribute sanity and performance tests: The system's test infrastructure is set up to test and run standard benchmarks and sanity tests in a uniform framework. This functionality helps foster reproducible performance results, and exercises the system nightly to shake out bugs. If you're adding new code to the system, please consider contributing tests for it.Contribute unit tests: Support for unit tests was recently added to the Jikes RVM by João Reys Santos for Google Summer of Code 2012. There is an initial set of tests but it is not very extensive. In the long term, we should have a unit test for almost every class.Contribute missing sections or clarifications to the User Guide: If you run across some problem or area that is not well-documented in the User Guide, please write a short section for inclusion. Also, please help us improve the installation section to cover any installation problems you run into that are not documented. If you are interested in contributing to the User Guide, or to other pieces of online documentation maintained in our wiki, we're quite willing to give you write access to the wiki pages. Please contact a Steering Committee member.Update the Publications and Dissertations pages: The lists of publications and dissertations are incomplete. You can inform members of the core team about missing publications or contact a Steering Committee member to request wiki access so that you can edit the pages yourself.Improve Javadoc comments in system code: We realize that the quality of Javadoc ™ comments is haphazard; please help us improve it.Confirm, triage or fix bugs: The issue tracker contains a lot of open bugs. If a bug interests you, try to reproduce and fix it. If you can't fix the bug but can provide a test case that reliably reproduces the bug, that is also very helpful. If you provide a fix, please consider providing test cases for the bug. Patches with test cases require less effort from the commiters and will reach the mainline sooner.Review commits and patches: You can review commits (subscribe to the commit mailing list to receive commit notifications) and patches on the issue tracker to improve code quality and catch bugs. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "update description of soft handshakes with respect to the new behaviour (collector threads do not take part)" This section ... [More] provides some explanation of how Java™ threads are scheduled and synchronized by Jikes™ RVM.All Java threads (application threads, garbage collector threads, etc.) derive from RVMThread. Each RVMThread maps directly to one native thread, which may be implemented using whichever C/C++ threading library is in use (currently either pthreads or Harmony threads). Unless -X:forceOneCPU is used, native threads are allowed to be arbitrarily scheduled by the OS using whatever processor resources are available; Jikes™ RVM does not attempt to control the thread-processor mapping at all.Using native threading gives Jikes™ RVM better compatibility for existing JNI code, as well as improved performance, and greater infrastructure simplicity. Scheduling is offloaded entirely to the operating system; this is both what native code would expect and what maximizes the OS scheduler's ability to optimally schedule Java™ threads. As well, the resulting VM infrastructure is both simpler and more robust, since instead of focusing on scheduling decisions it can take a "hands-off" approach except when Java threads have to be preempted for sampling, on-stack-replacement, garbage collection, Thread.suspend(), or locking. The main task of RVMThread and other code in org.jikesrvm.scheduler is thus to override OS scheduling decisions when the VM demands it.The remainder of this section is organized as follows. The management of a thread's state is discussed in detail. Mechanisms for blocking and handshaking threads are described. The VM's internal locking mechanism, the Monitor, is described. Finally, the locking implementation is discussed.Tracking the Thread StateThe state of a thread is broken down into two elements:Should the thread yield at a safe point?Is the thread running Java code right now?The first mechanism is provided by the RVMThread.takeYieldpoint field, which is 0 if the thread should not yield, or non-zero if it should yield at the next safe point. Negative versus positive values indicate the type of safe point to yield at (epilogue/prologue, or any, respectively).But this alone is insufficient to manage threads, as it relies on all threads being able to reach a safe point in a timely fashion. New Java threads may be started at any time, including at the exact moment that the garbage collector is starting; a starting-but-not-yet-started thread may not reach a safe point if the thread that was starting it is already blocked. Java threads may terminate at any time; terminated threads will never again reach a safe point. Any Java thread may call into arbitrary JNI code, which is outside of the VM's control, and may run for an arbitrary amount of time without reaching a Java safe point. As well, other mechanisms of RVMThread may cause a thread to block, thereby making it incapable of reaching a safe point in a timely fashion. However, in each of these cases, the Java thread is "effectively safe" - it is not running Java code that would interfere with the garbage collector, on-stack-replacement, locking, or any other Java runtime mechanism. Thus, a state management system is needed that would notify these runtime services when a thread is "effectively safe" and does not need to be waited on.RVMThread provides for the following thread states, which describe to other runtime services the state of a Java thread. These states are designed with extreme care to support the following features:Allow Java threads to either execute Java code, which periodically reaches safe points, and native code which is "effectively safe" by virtue of not having access to VM services.Allow other threads (either Java threads or VM threads) to asynchronously request a Java thread to block. This overlaps with the takeYieldpoint mechanism, but adds the following feature: a thread that is "effectively safe" does not have to block.Prevent race conditions on state changes. In particular, if a thread running native code transitions back to running Java code while some other thread expects it to be either "effectively safe" or blocked at a safe point, then it should block. As well, if we are waiting on some Java thread to reach a safe point but it instead escapes into running native code, then we would like to be notified that even though it is not at a safe point, it is not effectively safe, and thus, we do not have to wait for it anymore.The states used to put these features into effect are listed below.NEW. This means that the thread has been created but is not started, and hence is not yet running. NEW threads are always effectively safe, provided that they do not transition to any of the other states.IN_JAVA. The thread is running Java code. This almost always corresponds to the OS "runnable" state - i.e. the thread has no reason to be blocked, is on the runnable queue, and if a processor becomes available it will execute, if it is not already executing. IN_JAVA thread will periodically reach safe points at which the takeYieldpoint field will be tested. Hence, setting this field will ensure that the thread will yield in a timely fashion, unless it transitions into one of the other states in the meantime.IN_NATIVE. The thread is running either native C code, or internal VM code (which, by virtue of Jikes™ RVM's metacircularity, may be written in Java). IN_NATIVE threads are "effectively safe" in that they will not do anything that interferes with runtime services, at least until they transition into some other state. The IN_NATIVE state is most often used to denote threads that are blocked, for example on a lock.IN_JNI. The thread has called into JNI code. This is identical to the IN_NATIVE state in all ways except one: IN_JNI threads have a JNIEnvironment that stores more information about the thread's execution state (stack information, etc), while IN_NATIVE threads save only the minimum set of information required for the GC to perform stack scanning.IN_JAVA_TO_BLOCK. This represents a thread that is running Java code, as in IN_JAVA, but has been requested to yield. In most cases, when you set takeYieldpoint to non-zero, you will also change the state of the thread from IN_JAVA to IN_JAVA_TO_BLOCK. If you don't intend on waiting for the thread (for example, in the case of sampling, where you're opportunistically requesting a yield), then this step may be omitted; but in the cases of locking and garbage collection, when a thread is requested to yield using takeYieldpoint, its state will also be changed.BLOCKED_IN_NATIVE. BLOCKED_IN_NATIVE is to IN_NATIVE as IN_JAVA_TO_BLOCK is to IN_JAVA. When requesting a thread to yield, we check its state; if it's IN_NATIVE, we set it to be BLOCKED_IN_NATIVE.BLOCKED_IN_JNI. Same as BLOCKED_IN_NATIVE, but for IN_JNI.TERMINATED. The thread has died. It is "effectively safe", but will never again reach a safe point.The states are stored in RVMThread.execStatus, an integer field that may be rapidly manipulated using compare-and-swap. This field uses a hybrid synchronization protocol, which includes both compare-and-swap and conventional locking (using the thread's Monitor, accessible via the RVMThread.monitor() method). The rules are as follows:All state changes except for IN_JAVA to IN_NATIVE or IN_JNI, and IN_NATIVE or IN_JNI back to IN_JAVA, must be done while holding the lock.Only the thread itself can change its own state without holding the lock.The only asynchronous state changes (changes to the state not done by the thread that owns it) that are allowed are IN_JAVA to IN_JAVA_TO_BLOCK, IN_NATIVE to BLOCKED_IN_NATIVE, and IN_JNI TO BLOCKED_IN_JNI.The typical algorithm for requesting a thread to block looks as follows: thread.monitor().lockNoHandshake(); if (thread is running) { thread.takeYieldpoint=1; // transitions IN_JAVA -> IN_JAVA_TO_BLOCK, IN_NATIVE->BLOCKED_IN_NATIVE, etc. thread.setBlockedExecStatus(); if (thread.isInJava()) { // Thread will reach safe point soon, or else notify // us that it left to native code. // In either case, since we are holding the lock, // the thread will effectively block on either the safe point // or on the attempt to go to native code, since performing // either state transition requires acquiring the lock, // which we are now holding. } else { // Thread is in native code, and thus is "effectively safe", // and cannot go back to running Java code so long as we hold // the lock, since that state transition requires // acquiring the lock. } } thread.monitor().unlock(); Most of the time, you do not have to write such code, as the cases of blocking threads are already implemented. For examples of how to utilize these mechanisms, see RVMThread.block(), RVMThread.hardHandshakeSuspend(), and RVMThread.softHandshake(). A discussion of how to use these methods follows in the section below.Finally, the valid state transitions are as follows.NEW to IN_JAVA: occurs when the thread is actually started. At this point it is safe to expect that the thread will reach a safe point in some bounded amount of time, at which point it will have a complete execution context, and this will be able to have its stack traces by GC.IN_JAVA to IN_JAVA_TO_BLOCK: occurs when an asynchronous request is made, for example to stop for GC, do a mutator flush, or do an isync on PPC.IN_JAVA to IN_NATIVE: occurs when the code opts to run in privileged mode, without synchronizing with GC. This state transition is only performed by Monitor, in cases where the thread is about to go idle while waiting for notifications (such as in the case of park, wait, or sleep), and by org.jikesrvm.runtime.FileSystem, as an optimization to allow I/O operations to be performed without a full JNI transition.IN_JAVA to IN_JNI: occurs in response to a JNI downcall, or return from a JNI upcall.IN_JAVA_TO_BLOCK to BLOCKED_IN_NATIVE: occurs when a thread that had been asked to perform an async activity decides to go to privileged mode instead. This state always corresponds to a notification being sent to other threads, letting them know that this thread is idle. When the thread is idle, any asynchronous requests (such as mutator flushes) can instead be performed on behalf of this thread by other threads, since this thread is guaranteed not to be running any user Java code, and will not be able to return to running Java code without first blocking, and waiting to be unblocked (see BLOCKED_IN_NATIVE to IN_JAVA transition.IN_JAVA_TO_BLOCK to BLOCKED_IN_JNI: occurs when a thread that had been asked to perform an async activity decides to make a JNI downcall, or return from a JNI upcall, instead. In all other regards, this is identical to the IN_JAVA_TO_BLOCK to BLOCKED_IN_NATIVE transition.IN_NATIVE to IN_JAVA: occurs when a thread returns from idling or running privileged code to running Java code.BLOCKED_IN_NATIVE to IN_JAVA: occurs when a thread that had been asked to perform an async activity while running privileged code or idling decides to go back to running Java code. The actual transition is preceded by the thread first performing any requested actions (such as mutator flushes) and waiting for a notification that it is safe to continue running (for example, the thread may wait until GC is finished).IN_JNI to IN_JAVA: occurs when a thread returns from a JNI downcall, or makes a JNI upcall.BLOCKED_IN_JNI to IN_JAVA: same as BLOCKED_IN_NATIVE to IN_JAVA, except that this occurs in response to a return from a JNI downcall, or as the thread makes a JNI upcall.IN_JAVA to TERMINATED: the thread has terminated, and will never reach any more safe points, and thus will not be able to respond to any more requests for async activities.Blocking and HandshakingVarious VM services, such as the garbage collector and locking, may wish to request a thread to block. In some cases, we want to block all threads except for the thread that makes the request. As well, some VM services may only wish for a "soft handshake", where we wait for each non-collector thread to perform some action exactly once and then continue (in this case, the only thread that blocks is the thread requesting the soft handshake, but all other non-collector threads must "yield" in order to perform the requested action; in most cases that action is non-blocking). A unified facility for performing all of these requests is provided by RVMThread.Four types of thread blocking and handshaking are supported:RVMThread.block(). This is a low-level facility for requesting that a particular thread blocks. It is inherently unsafe to use this facility directly - for example, if thread A calls B.block() while thread B calls A.block(), the two threads may mutually deadlock.RVMThread.beginPairHandshake(). This implements a safe pair-handshaking mechanism, in which two threads become bound to each other for a short time. The thread requesting the pair handshake waits until the other thread is at a safe point or else is "effectively safe", and prevents it from going back to executing Java code. Note that at this point, neither thread will respond to any other handshake requests until RVMThread.endPairHandshake() is called. This is useful for implementing biased locking, but it has general utility anytime one thread needs to manipulate something another thread's execution state.RVMThread.softHandshake(). This implements soft handshakes. In a soft handshake, the requesting thread waits for all non-collector threads to perform some action exactly once, and then returns. If any of those threads are effectively safe, then the requesting thread performs the action on their behalf. softHandshake() is invoked with a SoftHandshakeVisitor that determines which threads are to be affected, and what the requested action is. An example of how this is used is found in org.jikesrvm.mm.mmtk.Collection and org.jikesrvm.compilers.opt.runtimesupport.OptCompiledMethod.RVMThread.hardHandshakeSuspend(). This stops all threads except for the garbage collector threads and the thread making the request. It returns once all Java threads are stopped. This is used by the garbage collector itself, but may be of utility elsewhere (for example, dynamic software updating). To resume all stopped threads, call RVMThread.hardHandshakeResume(). Note that this mechanism is carefully designed so that even after the world is stopped, it is safe to request a garbage collection (in that case, the garbage collector will itself call a variant of hardHandshakeSuspend(), but it will only affect the one remaining running Java thread).The Monitor APIThe VM internally uses an OS-based locking implementation, augmented with support for safe lock recursion and awareness of handshakes. The Monitor API provides locking and notification, similar to a Java lock, and may be implemented using either a pthread_mutex and a pthread_cond, or using Harmony's monitor API.Acquiring a Monitor lock, or awaiting notification, may cause the calling RVMThread to block. This prevents the calling thread from acknowledging handshakes until the blocking call returns. In some cases, this is desirable. For example:In the implementation of handshakes, the code already takes special care to use the RVMThread state machine to notify other threads that the caller may block. As such, acquiring a lock or waiting for a notification is safe.If acquiring a lock that may only be held for a short, guaranteed-bounded length of time, the fact that the thread will ignore handshake requests while blocking is safe - the lock acquisition request will return in bounded time, allowing the thread to acknowledge any pending handshake requests.But in all other cases, the calling thread must ensure that the handshake mechanism is notified that thread will block. Hence, all blocking Monitor methods have both a "NoHandshake" and "WithHandshake" version. Consider the following code: someMonitor.lockNoHandshake(); // perform fast, bounded-time critical section someMonitor.unlock(); // non-blocking In this code, lock acquisition is done without notifying handshakes. This makes the acquisition faster. In this case, it is safe because the critical section is bounded-time. As well, we require that in this case, any other critical sections protected by someMonitor are bounded-time as well. If, on the other hand, the critical section was not bounded-time, we would do: someMonitor.lockWithHandshake(); // perform potentially long critical section someMonitor.unlock(); In this case, the lockWithHandshake() operation will transition the calling thread to the IN_NATIVE state before acquiring the lock, and then transition it back to IN_JAVA once the lock is acquired. This may cause the thread to block, if a handshake is in progress. As an added safety provision, if the lockWithHandshake() operation blocks due to a handshake, it will ensure that it does so without holding the someMonitor lock.A special Monitor is provided with each thread. This monitor is of the type NoYieldpointsMonitor and will also ensure that yieldpoints (safe points) are disabled while the lock is held. This is necessary because any safe point may release the Monitor lock by waiting on it, thereby breaking atomicity of the critical section. The NoYieldpointsMonitor for any RVMThread may be accessed using the RVMThread.monitor() method.Additional information about how to use this API is found in the following section, which discusses the implementation of Java locking.Thin and Biased LockingJikes™ RVM uses a hybrid thin/biased locking implementation that is designed for very high performance under any of the following loads:Locks only ever acquired by one thread. In this case, biased locking is used, an no atomic operations (like compare-and-swap) need to be used to acquire and release locks.Locks acquired by multiple threads but rarely under contention. In this case, thin locking is used; acquiring and releasing the lock involves a fast inlined compare-and-swap operation. It is not as fast as biased locking on most architectures.Contended locks. Under sustained contention, the lock is "inflated" - the lock will now consist of data structures used to implement a fast barging FIFO mutex. A barging FIFO mutex allows threads to immediately acquire the lock as soon as it is available, or otherwise enqueue themselves on a FIFO and await its availability.Thin locking has a relatively simple implementation; roughly 20 bits in the object header are used to represent the current lock state, and compare-and-swap is used to manipulate it. Biased locking and contended locking are more complicated, and are described below.Biased locking makes the optimistic assumption that only one thread will ever want to acquire the lock. So long as this assumption holds, acquisition of the lock is a simple non-atomic increment/decrement. However, if the assumption is violated (a thread other than the one to which the lock is biased attempts to acquire the lock), a fallback mechanism is used to turn the lock into either a thin or contended lock. This works by using RVMThread.beginPairHandshake() to bring both the thread that is requesting the lock and the thread to which the lock is biased to a safe point. No other threads are affected; hence this system is very scalable. Once the pair handshake begins, the thread requesting the lock changes the lock into either a thin or contended lock, and then ends the pair handshake, allowing the thread to which the lock was biased to resume execution, while the thread requesting the lock may now contend on it using normal thin/contended mechanisms.Contended locks, or "fat locks", consist of three mechanisms:A spin lock to protect the data structures.A queue of threads blocked on the lock.A mechanism for blocked threads to go to sleep until awoken by being dequeued.The spin lock is a org.jikesrvm.scheduler.SpinLock. The queue is implemented in org.jikesrvm.scheduler.ThreadQueue. And the blocking/unblocking mechanism leverages org.jikesrvm.scheduler.Monitor; in particular, it uses the Monitor that is attached to each thread, accessible via RVMThread.monitor(). The basic algorithm for lock acquisition is: spinLock.lock(); while (true) { if (lock available) { acquire the lock; break; } else { queue.enqueue(me); spinLock.unlock(); me.monitor().lockNoHandshake(); while (queue.isQueued(me)) { // put this thread to sleep waiting to be dequeued, // and do so while the thread is IN_NATIVE to ensure // that other threads don't wait on this one for // handshakes while we're blocked. me.monitor().waitWithHandshake(); } me.monitor().unlock(); spinLock.lock(); } } spinLock.unlock(); The algorithm for unlocking dequeues the thread at the head of the queue (if there is one) and notifies its Monitor using the lockedBroadcastNoHandshake() method. Note that these algorithms span multiple methods in org.jikesrvm.scheduler.ThinLock and org.jikesrvm.scheduler.Lock; in particular, lockHeavy(), lockHeavyLocked(), unlockHeavy(), lock(), and unlock(). View Online · View Changes Online [Less]

Page edited by Erik Brangs - "mention new target for running unit tests on an existing image" Jikes RVM includes provisions to run unit tests as well as ... [More] functional and performance tests. It also includes a number of actual tests, both unit and functional ones.Unit TestsJikes RVM makes writing simple unit tests easy. Simply give your JUnit 4 tests a name ending in Test and place test sources under rvm/test-src. The tests will be picked up automatically.The tests are then run on the bootstrap VM, i.e. the JVM used to build Jikes RVM. You can also configure the build to run unit tests on the newly built Jikes RVM. Note that this may significantly increase the build times of slow configurations (e.g. prototype and protype-opt).If you are developing new unit tests, it may be helpful to run them on an existing Jikes RVM image. This can be done by using the Ant target unit-tests-on-existing-image. The path for the image is determined by the usual properties of the Ant build.Functional and Performance TestsSee External Test Resources for details or downloading prerequisites for the functional tests. The tests are executed using an Ant build file and produce results that conform to the definition below. The results are aggregated and processed to produce a high level report defining the status of Jikes RVM.The testing framework was designed to support continuous and periodical execution of tests. A "test-run" occurs every time the testing framework is invoked. Every "test-run" will execute one or more "test-configuration"s. A "test-configuration" defines a particular build "configuration" (See Configuring the RVM for details) combined with a set of parameters that are passed to the RVM during the execution of the tests. i.e. a particular "test-configuration" may pass parameters such as -X:aos:enable_recompilation=false -X:aos:initial_compiler=opt -X:irc:O1 to test the Level 1 Opt compiler optimizations.Every "test-configuration" will execute one or more "group"s of tests. Every "group" is defined by a Ant build.xml file in a separate sub-directory of $RVM_ROOT/testing/tests. Each "test" has a number of input parameters such as the classname to execute, the parameters to pass to the RVM or to the program. The "test" records a number of values such as execution time, exit code, result, standard output etc. and may also record a number of statistics if it is a performance test.The project includes several different types of _test run_s and the description of each the test runs and their purpose is given in Test Run Descriptions.NoteThe buildit script provides a fast and easy way to build and the system.  The script is simply a wrapper around the mechanisms described below.Ant PropertiesThere is a number of ant properties that control the test process. Besides the properties that are already defined in Building the RVM the following properties may also be specified.PropertyDescriptionDefaulttest-run.nameThe name of the test-run. The name should match one of the files located in the build/test-runs/ directory minus the '.properties' extension.pre-commitresults.dirThe directory where Ant stores the results of the test run.${jikesrvm.dir}/resultsresults.archiveThe directory where Ant gzips and archives a copy of test run results and reports.${results.dir}/archivesend.reportsDefine this property to send reports via email.(Undefined)mail.fromThe from address used when emailing [email protected] to address used when emailing [email protected] host to connect to when sending mail.localhostmail.portThe port to connect to when sending mail.25<configuration>.builtIf set to true, the test process will skip the build step for specified configurations. For the test process to work the build must already be present.(Undefined)skip.buildIf defined the test process will skip the build step for all configurations and the javadoc generation step. For the test process to work the build must already be present.(Undefined)skip.javadocIf defined the test process will skip the javadoc generation step.(Undefined)Defining a test-runA test-run is defined by a number of properties located in a property file located in the build/test-runs/ directory.The property test.configs is a whitespace separated list of test-configuration "tags". Every tag uniquely identifies a particular test-configuration. Every test-configuration is defined by a number of properties in the property file that are prefixed with test.config.<tag>. and the following table defines the possible properties.PropertyDescriptionDefaulttestsThe names of the test groups to execute.NonenameThe unique identifier for test-configuration.""configurationThe name of the RVM build configuration to test.<tag>targetThe name of the RVM build target. This can be used to trigger compilation of a profiled image"main"modeThe test mode. May modify the way test groups execute. See individual groups for details.""extra.rvm.argsExtra arguments that are passed to the RVM. These may be varied for different runs using the same image.""NoteThe order of the test-configurations in test.configs is the order that the test-configurations are tested. The order of the groups in test.config.<tag>.test is the order that the tests are executed.The simplest test-run is defined in the following figure. It will use the build configuration "prototype" and execute tests in the "basic" group.build/test-runs/simple.properties test.configs=prototype test.config.prototype.tests=basic The test process also expands properties in the property file so it is possible to define a set of tests once but use them in multiple test-configurations as occurs in the following figure. The groups basic, optests and dacapo are executed in both the prototype and prototype-opt test\configurations.build/test-runs/property-expansion.properties test.set=basic optests dacapo test.configs=prototype prototype-opt test.config.prototype.tests=${test.set} test.config.prototype-opt.tests=${test.set} Test Specific ParametersEach test can have additional parameters specified that will be used by the test infrastructure when starting the Jikes RVM instance to execute the test. These additional parameters are described in the following table.ParameterDescriptionDefault PropertyDefault Valueinitial.heapsizeThe initial size of the heap.${test.initial.heapsize}${config.default-heapsize.initial}max.heapsizeThe initial size of the heap.${test.max.heapsize}${config.default-heapsize.maximum}max.opt.levelThe maximum optimization level for the tests or an empty string to use the Jikes RVM default.${test.max.opt.level}""processorsThe number of processors to use for garbage collection for the test or 'all' to use all available processors.${test.processors}alltime.limitThe time limit for the test in seconds. After the time limit expires the Jikes RVM instance will be forcefully terminated.${test.time.limit}1000class.pathThe class path for the test.${test.class.path} extra.argsExtra arguments that are passed to the RVM.${test.rvm.extra.args}""excludeIf set to true, the test will be not be executed. ""To determine the value of a test specific parameters, the following mechanism is used;Search for one of the the following ant properties, in order.test.config.<build-configuration>.<group>.<test>.<parameter>test.config.<build-configuration>.<group>.<parameter>test.config.<build-configuration>.<parameter>test.config.<build-configuration>.<group>.<test>.<parameter>test.config.<build-configuration>.<group>.<parameter>If none of the above properties are defined then use the parameter that was passed to the <rvm> macro in the ant build file.If no parameter was passed to the <rvm> macro then use the default value which is stored in the "Default Property" as specified in the above table. By default the value of the "Default Property" is specified as the "Default Value" in the above table, however a particular build file may specify a different "Default Value".Excluding testsSometimes it is desirable to exclude tests. The test exclusion may occur as the test is known to fail on a particular target platform, build configuration or maybe it just takes too long. To exclude a test, you must define the test specific parameter "exclude" to true either in .ant.properties or in the test-run properties file.i.e. At the time of writing the Jikes RVM does not fully support volatile fields and as a result th test named "TestVolatile" in the "basic" group will always fail. Rather than being notified of this failure we can disable the test by adding a property such as "test.config.basic.TestVolatile.exclude=true" into test-run properties file.Executing a test-runThe tests are executed by the Ant driver script test.xml. The test-run.name property defines the particular test-run to execute and if not set defaults to "sanity". The command ant -f test.xml -Dtest-run.name=simple executes the test-run defined in build/test-runs/simple.properties. When this command completes you can point your browser at ${results.dir}/tests/${test-run.name}/Report.html to get an overview on test run or at ${results.dir}/tests/${test-run.name}/Report.xml for an xml document describing test results. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "added update of publications and dissertations pages to low-hanging fruit; fix typo" The Jikes RVM project aims to provide a ... [More] high-quality state-of-the-art open-source infrastructure for programming language research. Of course, this requires a significant investment in system maintenance and enhancement, to keep the system running on new environments and to keep up with the latest innovations in language design and implementation practice.Feedback and contributions from the research community are the indispensable, invaluable resource that will ensure the project's continued success. Please help to improve some aspect of the system; no improvement is too small or too simple! The more volunteers can contribute, the better the system will serve the research community, resulting in faster and more solid research results. It is also a great help to the community if you contribute your code to the research archive.How can you help Jikes RVM?Jikes RVM is a fairly large, complex, and perhaps intimidating system. However, there are many to-do items which don't require extensive Jikes RVM expertise.This page highlights a selection of low-hanging fruit for potential contributions. This list is of course nowhere near comprehensive, but exists just as a sampling of potential activities. Additional ideas that require code contributions are listed on a separate page.All contributions to Jikes RVM are managed in our JIRA-based issue tracker.Please let us know if the list below is out-of-date by entering a bug against the website.Some low-hanging fruit in no particular orderContribute sanity and performance tests: The system's test infrastructure is set up to test and run standard benchmarks and sanity tests in a uniform framework. This functionality helps foster reproducible performance results, and exercises the system nightly to shake out bugs. If you're adding new code to the system, please consider contributing tests for it.Contribute unit tests: Support for unit tests was recently added to the Jikes RVM by João Reys Santos for Google Summer of Code 2012. There is an initial set of tests but it is not very extensive. In the long term, we should have a unit test for almost every class.Contribute missing sections or clarifications to the User Guide: If you run across some problem or area that is not well-documented in the User Guide, please write a short section for inclusion. Also, please help us improve the installation section to cover any installation problems you run into that are not documented. If you are interested in contributing to the User Guide, or to other pieces of online documentation maintained in our wiki, we're quite willing to give you write access to the wiki pages. Please contact a Steering Committee member.Update the Publications and Dissertations pages: The lists of publications and dissertations are incomplete. You can inform members of the core team about missing publications or contact a Steering Committee member to request wiki access so that you can edit the pages yourself.Improve Javadoc comments in system code: We realize that the quality of Javadoc ™ comments is haphazard; please help us improve it.Confirm, triage or fix bugs: The issue tracker contains a lot of open bugs. If a bug interests you, try to reproduce and fix it. If you can't fix the bug but can provide a test case that reliably reproduces the bug, that is also very helpful. If you provide a fix, please consider providing test cases for the bug. Patches with test cases require less effort from the commiters and will reach the mainline sooner.Review commits and patches: You can review commits (subscribe to the commit mailing list to receive commit notifications) and patches on the issue tracker to improve code quality and catch bugs. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "added link for "Runtime Value Specialization"" Below is a list of all dissertations that use Jikes RVM. We strongly encourage ... [More] authors to utilize the Research Archive to publish source code used in their studies, and thus, allow others to build on their results. For information on reviewed papers, see the main Publications page.2012The Design and Construction of High Performance Garbage CollectorsRobin GarnerPhD, School of Computer Science, The Australian National University2011Locality Aware Zeroing: Exploiting Both Hardware and Software SemanticsXi YangMPhil, School of Computer Science, The Australian National University2010Garbage Collection and the Case for High-level Low-level ProgramingDaniel FramptonPhD, School of Computer Science, The Australian National University2008Diagnosing and Tolerating Bugs in Deployed SystemsMichael D. BondPhD, Computer Sciences, The University of Texas at AustinFast, Effective Program Analysis for Object-Level ParallelismWilliam C. BentonPhD, University of Wisconsin-MadisonProfiling Techniques for Performance Analysis and Optimization of Java ApplicationsDries BuytaertPhD in Computer Science and Engineering from Ghent UniversityThree Pitfalls in Java Performance EvaluationAndy GeorgesPhD in Computer Science and Engineering from Ghent UniversityProgramming with Transactional MemoryBrian D. CarlstromPhD in Computer Science, Department of Computer Science, Stanford UniversityAutomatic Parallelization for Graphics Processing Units in JikesRVMAlan Chun-Wai LeungMaster of Mathematics in Computer Science, Waterloo, Ontario, Canada, 2008The Issue of Strong Mobility: an Innovative Approach based on the IBM Jikes Research Virtual MachineRaffaele QuitadamoPhD in Computer Science and Engineering, Department of Computer Science and Engineering, University of Modena and R. Emilia, Italy.2007Adaptive Parallelization and Optimization for the JAMAICA Chip Multi-Processor ArchitectureJisheng ZhaoPh.D thesis, School of Computer Science, University of Manchester.Runtime Value SpecializationPanagiota BilianouMPhil thesis, School of Computer Science, University of Manchester.Note: available via the Electronic Thesis Online Service of the British Library (needs registration)Emulating the ARM Architecture Using a Java Dynamic Binary TranslatorMichael BaerMSc thesis, School of Computer Science, University of Manchester.Configurable JVM ThreadingRahul MehtaMSc thesis, School of Computer Science, University of Manchester.2006Concurrency abstractions for object-oriented programming languages using optimistic protocolsWelc A.PhD dissertation, Purdue University, May 2006.An improved generational copying garbage collectorMcGachey P.MS thesis, Purdue University, May 2006.Quantifying and Improving the Performance of Garbage CollectionMatthew HertzPh.D thesis, Dept. of Computer Science, University of Massachusetts.Memory Management Strategies to Improve the Space-Time Performance of Java ProgramsYu Ching HanPh.D thesis, Systems Research Group, Department of Computer Science, The University of Hong KongA Java Virtual Machine Extended to Run Parrot BytecodeMartin DahlMSc thesis, Dept. of Computer Science, University of Manchester.Design and Implementation of a Baseline port of the Jikes Research Virtual Machine to the IA-64 ArchitectureRavi kiran GorrepatiMaster's thesis, The University of New Mexico, Albuquerque, New MexicoAdding an Interpreter to the Jikes RVMAnastasios KatsigiannisMSc thesis, Dept. of Computer Science, University of Manchester.Parallelizing the Jikes Research Virtual MachineChristos KotselidisMSc thesis, Dept. of Computer Science, University of Manchester.Dynamically Improving Program Locality on-the-FlyXianglong HuangPh.D thesis, Dept. of Computer Sciences, University of Texas at Austin2005An X86 Emulator Written Using JavaJohn BurchamMSc thesis, Dept. of Computer Science, University of Manchester.Jikes RVM voor een 64-bit x86 platformFrederik De SchrijverThesisVirtual Machine Support for Aspect-Oriented Programming LanguagesMichael HauptDissertationUnderstanding Program Performance Using Temporal Vertical ProfilingMatthias HauswirthDoctoral Dissertation, Computer Science Department, the University of Colorado at BoulderA Space-Aware AMD64 Port of Jikes RVMArun Thomas, Dan WilliamsCS771 Project, Department of Computer Science, School of Engineering, University of VirginiaMemory Management in JikesNode Operating SystemYun ZhangMSc thesis, Dept. of Computer Science, University of Manchester.2004Automatically Constructing Compiler Optimization Heuristics Using Supervised LearningJohn CavazosPh.D thesis, Dept. of Computer Science, University of Massachusetts.A Java Virtual Machine For The ARM ProcessorMing ChenMSc thesis, Dept. of Computer Science, University of Manchester.JikesNODE: A Java Operating SystemGeorgios GousiosMSc thesis, Dept. of Computer Science, University of Manchester.Connectivity-Based Garbage CollectionMartin HirzelPhD thesis, Dept. of Computer Science, University of Colorado at Boulder.Native Code Execution Within a JVMRichard MatleyMSc thesis, Dept. of Computer Science, University of Manchester.Partial Redundancy Elimination for Global Value NumberingThomas VanDrunenPhD Thesis, Purdue University.Jikes RVM Adaptive Optimization System with Intelligent AlgorithmsJisheng ZhaoMSc thesis, Dept. of Computer Science, University of Manchester.2003Incorporating Domain-Specific Information into the Compilation ProcessSamuel Z. GuyerDoctoral dissertation, Department of Computer Sciences, the University of Texas at AustinJikes Research Virtual Machine - design and implementation of a 64-bit PowerPC portS. KyrylkovMaster's thesis, University of New Mexico.JMTk: A portable memory management toolkitRobin GarnerHonours thesis, Australian National University.A Framework for Optimistic Program OptimizationIgor Peshansky, (former last name: Pechtchanski)Ph.D thesis, Department of Computer Science, New York University2002Online Profiling and Feedback-Directed Optimization of JavaMatthew ArnoldPh.D Thesis, Rutgers UniversityData Reorganization for Improving Cache Performance of Object-Oriented ProgramsSharad SinghaiPh.D Thesis, University of Massachusetts2001Reducing Load Delay to Improve Performance of Internet-Computing ProgramsChandra KrintzPh.D Thesis, University of California, San Diego1999Dynamic Optimization through the use of Automatic Runtime SpecializationJohn WhaleyM.Eng. thesis, Massachusetts Institute of Technology. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "hopefully fixed whitespace issues for low-hanging fruit section" The Jikes RVM project aims to provide a high-quality ... [More] state-of-the-art open-source infrastructure for programming language research. Of course, this requires a significant investment in system maintenance and enhancement, to keep the system running on new environments and to keep up with the latest innovations in language design and implementation practice.Feedback and contributions from the research community are the indispensable, invaluable resource that will ensure the project's continued success. Please help to improve some aspect of the system; no improvement is too small or too simple! The more volunteers can contribute, the better the system will serve the research community, resulting in faster and more solid research results. It is also a great help to the community if you contribute your code to the research archive.How can you help Jikes RVM?Jikes RVM is a fairly large, complex, and perhaps intimidating system. However, there are many to-do items which don't require extensive Jikes RVM expertise.This page highlights a selection of low-hanging fruit for potential contributions. This list is of course nowhere near comprehensive, but exists just as a sampling of potential activities. Additional ideas that require code contributions are listed on a separate page.All contributions to Jikes RVM are managed in our JIRA-based issue tracker.Please let us know if the list below is out-of-date by entering a bug against the website.Some low-hanging fruit in no particular orderContribute sanity and performance tests: The system's test infrastructure is set up to test and run standard benchmarks and sanity tests in a uniform framework. This functionality helps foster reproducible performance results, and exercises the system nightly to shake out bugs. If you're adding new code to the system, please consider contributing tests for it.Contribute unit tests: Support for unit tests was recently added to the Jikes RVM by João Reys Santos for Google Summer of Code 2012. There is an initial set of tests but it is not very extensive. In the long term, we should have a unit test for almost every class.Contribute missing sections or clarifications to the User Guide: If you run across some problem or area that is not well-documented in the User Guide, please write a short section for inclusion. Also, please help us improve the installation section to cover any installation problems you run into that are not documented. If you are interesting in contributing to the User Guide, or to other pieces of online documentation maintained in our wiki, we're quite willing to give you write access to the wiki pages. Please contact a Steering Committee member.Improve Javadoc comments in system code: We realize that the quality of Javadoc ™ comments is haphazard; please help us improve it.Confirm, triage or fix bugs: The issue tracker contains a lot of open bugs. If a bug interests you, try to reproduce and fix it. If you can't fix the bug but can provide a test case that reliably reproduces the bug, that is also very helpful. If you provide a fix, please consider providing test cases for the bug. Patches with test cases require less effort from the commiters and will reach the mainline sooner.Review commits and patches: You can review commits (subscribe to the commit mailing list to receive commit notifications) and patches on the issue tracker to improve code quality and catch bugs. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "minor improvements to the information about non-standard options" Jikes™ RVM executes Java virtual machine byte code instructions ... [More] from .class files. It does not compile Java™ source code. Therefore, you must compile all Java source files into bytecode using your favorite Java compiler.For example, to run class foo with source code in file foo.java: % javac foo.java % rvm foo The general syntax is rvm [rvm options...] class [args...] You may choose from a myriad of options for the rvm command-line. Options fall into two categories: standard and non-standard. Non-standard options are preceded by "-X:" and differ between virtual machines (e.g. Jikes RVM's options may not be available in HotSpot and vice-versa).Standard Command-Line OptionsWe currently support a subset of the JDK 1.5 standard options. Below is a list of all options and their descriptions. Unless otherwise noted each option is supported in Jikes RVM.OptionDescription{-cp or -classpath} <directories and zip/jar files separated by ":">set search path for application classes and resources-D<name>=<value>set a system property-verbose:[ class | gc | jni ]enable verbose output-versionprint current VM version and terminate the run-showversionprint current VM version and continue running-fullversionlike "-version", but with more information-? or -helpprint help message-Xprint help on non-standard options-jarexecute a jar file-javaagent:<jarpath>[=<options>]load Java programming language agent, see java.lang.instrumentNon-Standard Command-Line OptionsThe non standard command-line options are grouped according to the subsystem that they control. The following sections list the available options in each group.Note that the non-standard options may change from one release to another. To get a definite list, use the -X option and related options (e.g. -X:gc) on the image that you have built.Core Non-Standard Command-Line OptionsOptionDescription-X:verbosePrint out additional lowlevel information for GC and hardware trap handling-X:verboseBoot=<number>Print out additional information while VM is booting, using verbosity level <number>-X:sysLogfile=<filename>Write standard error message to <filename>-X:ic=<filename>Read boot image code from <filename>-X:id=<filename>Read boot image data from <filename>-X:ir=<filename>Read boot image ref map from <filename>-X:vmClasses=<path>Load the org.jikesrvm.* and java.* classes from <path>-X:processors=<number|"all">The number of processors that the garbage collector will useMemory Non-Standard Command-Line OptionsOptionDescription-Xms<number><unit>Initial size of heap where <number> is an integer, an extended-precision floating point or a hexadecimal value and <unit> is one of T (Terabytes), G (Gigabytes), M (Megabytes), pages (of size 4096), K (Kilobytes) or <no unit> for bytes-Xmx<number><unit>Maximum size of heap. See above for definition of <number> and <unit>Garbage Collector Non-Standard Command-Line OptionsThese options are all prefixed by -X:gc:.Boolean options.OptionDescriptionprotectOnReleaseShould memory be protected on release?echoOptionsEcho when options are set?printPhaseStatsWhen printing statistics, should statistics for each gc-mutator phase be printed?xmlStatsPrint end-of-run statistics in XML formateagerCompleteSweepShould we eagerly finish sweeping at the start of a collectionfragmentationStatsShould we print fragmentation statistics for the free list allocator?verboseFragmentationStatsShould we print verbose fragmentation statistics for the free list allocator?verboseTimingShould we display detailed breakdown of where GC time is spent?noFinalizerShould finalization be disabled?noReferenceTypesShould reference type processing be disabled?fullHeapSystemGCShould a major GC be performed when a system GC is triggered?ignoreSystemGCShould we ignore calls to java.lang.System.gc?variableSizeHeapShould we shrink/grow the heap to adjust to application working set?eagerMmapSpacesIf true, all spaces are eagerly demand zero mmapped at boot timesanityCheckPerform sanity checks before and after each collection?Value options.OptionTypeDescriptionmarkSweepMarkBitsintNumber of bits to use for the header cycle of mark sweep spacesverboseintGC verbosity levelstressFactorbytesForce a collection after this much allocationmetaDataLimitbytesTrigger a GC if the meta data volume grows to this limitboundedNurserybytesBound the maximum size of the nursery to this valuefixedNurserybytesFix the minimum and maximum size of the nursery to this valuedebugAddressaddressSpecify an address at runtime for use in debuggingBase Compiler Non-Standard Command-Line OptionsBoolean optionsOptionDescriptionedge_countersInsert edge counters on all bytecode-level conditional branchesinvocation_countersSelect methods for optimized recompilation by using invocation countersOpt Compiler Non-Standard Command-Line OptionsBoolean options.OptionDescriptionlocal_constant_propPerform local constant propagationlocal_copy_propPerform local copy propagationlocal_csePerform local common subexpression eliminationglobal_boundsPerform global Array Bound Check elimination on Demandmonitor_removalTry to remove unnecessary monitor operationsinvokee_thread_localCompile the method assuming the invokee is thread-localno_callee_exceptionsAssert that any callee of this compiled method will not throw exceptions?simple_escape_ipaEagerly compute method summaries for simple escape analysisfield_analysisEagerly compute method summaries for flow-insensitive field analysisscalar_replace_aggregatesPerform scalar replacement of aggregatesreorder_codeReorder basic blocks for improved locality and branch predictionreorder_code_phReorder basic blocks using Pettis and Hansen Algo2inline_newInline allocation of scalars and arraysinline_write_barrierInline write barriers for generational collectorsinlineInline statically resolvable callsguarded_inlineGuarded inlining of non-final virtual callsguarded_inline_interfaceSpeculatively inline non-final interface callsstatic_splittingCFG splitting to create hot traces based on static heuristicsredundant_branch_eliminationEliminate redundant conditional branchespreex_inlinePre-existence based inliningssaShould SSA form be constructed on the HIR?load_eliminationShould we perform redundant load elimination during SSA pass?coalesce_after_ssaShould we coalesce move instructions after leaving SSA?expression_foldingShould we try to fold expressions with constants in SSA form?live_range_splittingSplit live ranges using LIR SSA pass?gcpPerform global code placementgcsePerform global code placementverbose_gcpPerform noisy global code placementlicm_ignore_peiAssume PEIs do not throw or state is not observableunwhileTurn whiles into untilsloop_versioningLoop versioninghandler_livenessStore liveness for handlers to improve dependence graph at PEIsschedule_prepassPerform prepass instruction schedulingno_checkcastShould all checkcast operations be (unsafely) eliminated?no_checkstoreShould all checkstore operations be (unsafely) eliminated?no_bounds_checkShould all bounds check operations be (unsafely) eliminated?no_null_checkShould all null check operations be (unsafely) eliminated?no_synchroShould all synchronization operations be (unsafely) eliminated?no_threadsShould all yield points be (unsafely) eliminated?no_cache_flushShould cache flush instructions (PowerPC SYNC/ISYNC) be omitted? NOTE: Cannot be correctly changed via the command line!reads_killShould we constrain optimizations by enforcing reads-kill?monitor_nopShould we treat all monitorenter/monitorexit bytecodes as nops?static_statsShould we dump out compile-time statistics for basic blocks?code_patch_nopShould all patch point be (unsafely) eliminated (at initial HIR)?instrumentation_samplingPerform code transformation to sample instrumentation code.no_duplicationWhen performing inst. sampling, should it be done without duplicating code?processor_specific_counterShould there be one CBS counter per processor for SMP performance?remove_yp_from_checkingShould yieldpoints be removed from the checking code (requires finite sample interval).Value options.OptionDescriptionic_max_target_sizeStatic inlining heuristic: Upper bound on callee sizeic_max_inline_depthStatic inlining heuristic: Upper bound on depth of inliningic_max_always_inline_target_sizeStatic inlining heuristic: Always inline callees of this size or smalleric_massive_method_sizeStatic inlining heuristic: If root method is already this big, then only inline trivial methodsai_max_target_sizeAdaptive inlining heuristic: Upper bound on callee sizeai_min_callsite_fractionAdaptive inlining heuristc: Minimum fraction of callsite distribution for guarded inlining of a calleeedge_count_input_fileInput file of edge counter profile datainlining_guardSelection of guard mechanism for inlined virtual calls that cannot be statically boundfp_modeSelection of strictness level for floating point computationsexcludeExclude methods from being opt compiledunroll_logUnroll loops. Duplicates the loop body 2^n times.cond_move_cutoffHow many extra instructions will we insert in order to remove a conditional branch?load_elimination_roundsHow many rounds of redundant load elimination will we attempt?alloc_advice_sitesRead allocation advice attributes for all classes from this filefrequency_strategyHow to compute block and edge frequencies?spill_cost_estimateSelection of spilling heuristicinfrequent_thresholdCumulative threshold which defines the set of infrequent basic blockscbs_hotnessThreshold at which a conditional branch is considered to be skewedir_print_levelOnly print IR compiled above this levelAdaptive System Non-Standard Command-Line OptionsBoolean optionsOptionDescriptionenable_recompilation Should the adaptive system recompile hot methods?enable_advice_generationDo we need to generate advice file?enable_precompileShould the adaptive system precompile all methods given in the advice file before the user thread is started?enable_replay_compileShould the adaptive system use the pseudo-adaptive system that solely relies on the advice file?gather_profile_dataShould profile data be gathered and reported at the end of the run?adaptive_inliningShould we use adaptive feedback-directed inlining?early_exitShould AOS exit when the controller clock reaches early_exit_value?osr_promotionShould AOS promote baseline-compiled methods to opt?background_recompilationShould recompilation be done on a background thread or on next invocation?insert_yieldpoint_countersInsert instrumentation in opt recompiled code to count yieldpoints executed?insert_method_counters_optInsert intrusive method counters in opt recompiled code?insert_instruction_countersInsert counters on all instructions in opt recompiled code?insert_debugging_countersEnable easy insertion of (debugging) counters in opt recompiled code.report_interrupt_statsReport stats related to timer interrupts and AOS listeners on exit.disable_recompile_all_methodsDisable the ability for an app to request all methods to be recompiled.Value optionsOptionDescriptionmethod_sample_sizeHow many timer ticks of method samples to take before reporting method hotness to controller.initial_compilerSelection of initial compiler.recompilation_strategySelection of mechanism for identifying methods for optimizing recompilation.method_listener_triggerWhat triggers us to take a method sample?call_graph_listener_triggerWhat triggers us to take a method sample?logfile_name Name of log file.compilation_advice_file_outputName of advice file.dynamic_call_file_outputName of dynamic call graph file.compiler_dna_fileName of compiler DNA file (no name ==> use default DNA).  Discussed in a comment at the head of VM_CompilerDNA.java.compiler_advice_file_inputFile containing information about the methods to Opt compile.dynamic_call_file_inputFile containing information about the hot call sites.logging_levelControl amount of event logging (larger ==> more).final_report_levelControl amount of info reported on exit (larger ==> more).decay_frequencyAfter how many clock ticks should we decay.dcg_decay_rateWhat factor should we decay call graph edges hotness by.dcg_sample_sizeAfter how many timer interrupts do we update the weights in the dynamic call graph?ai_seed_multiplierInitial edge weight of call graph is set to ai_seed_multiplier * (1/ai_control_point).offline_inline_plan_nameName of offline inline plan to be read and used for inlining.early_exit_timeValue of controller clock at which AOS should exit if early_exit is true.invocation_count_thresholdInvocation count at which a baseline compiled method should be recompiled.invocation_count_opt_levelOpt level for recompilation in invocation count based system.counter_based_sample_intervalWhat is the sample interval for counter-based sampling.ai_hot_callsite_thresholdWhat percentage of the total weight of the dcg demarcates warm/hot edges.max_opt_levelThe maximum optimization level to enable.Virtual Machine Non-Standard Command-Line OptionsBoolean OptionsOptionDescriptionmeasureCompilationTime all compilations and report on exit.measureCompilationPhasesTime all compilation sub-phases and report on exit.stackTraceFullStack traces to consist of VM and application frames.stackTraceAtExitDump a stack trace (via VM.syswrite) upon exit.verboseTraceClassLoadingMore detailed tracing then -verbose:class.errorsFatalExit when non-fatal errors are detected; used for regression testing. Value optionsOptionDescriptionmaxSystemTroubleRecursionDepthIf we get deeper than this in one of the System Trouble functions, try to die.interruptQuantumTimer interrupt scheduling quantum in ms.schedulingMultiplierScheduling quantum = interruptQuantum * schedulingMultiplier.traceThreadSchedulingTrace actions taken by thread scheduling.verboseStackTracePeriodTrace every nth time a stack trace is created.edgeCounterFileInput file of edge counter profile data.CBSCallSamplesPerTickHow many CBS call samples (Prologue/Epilogue) should we take per time tick.CBSCallSampleStrideStride between each CBS call sample (Prologue/Epilogue) within a sampling window.CBSMethodSamplesPerTickHow many CBS method samples (any yieldpoint) should we take per time tick.CBSMethodSampleStrideStride between each CBS method sample (any yieldpoint) within a sampling window.countThreadTransitionsCount, and report, the number of thread state transitions. This works better on IA32 than on PPC at the moment.forceOneCPUForce all threads to run on one CPU. The argument specifies which CPU (starting from 0). Running Jikes RVM with valgrind Jikes RVM can run under valgrind, as of SVN revision 6791 (29-Aug-2007).  Applying a patch of this revision to release 3.2.1 should also produce a working system.  Versions of valgrind CVS prior to release 3.0 are also known to have worked.To run a Jikes RVM build with valgrind, use the -wrap flag to invoke valgrind, eg rvm -wrap "path/to/valgrind --smc-check=all <valgrind-options>" <jikesrvm-options> ... this will insert the invocation of valgrind at the appropriate place for it to operate on Jikes RVM proper rather than a wrapper script. Under some circumstances, valgrind will load shared object libraries or allocate memory in areas of the heap that conflict with Jikes RVM.  Using the flag -X:gc:eagerMmapSpaces=true will prevent and/or detect this.  If this flag reveals errors while mapping the spaces, you will need to rearrange the heap to avoid the addresses that valgrind is occupying. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "added a section about crashes and deadlocks " This section provides some tips on collecting performance numbers with Jikes ... [More] RVM.Which boot image should I use?To make a long story short the best performing configuration of Jikes RVM will almost always be production. Unless you really know what you are doing, don't use any other configuration to do a performance evaluation of Jikes RVM.Any boot image you use for performance evaluation must have the following characteristics for the results to be meaningful:config.assertions=none. Unless this is set, the runtime system and optimizing compiler will perform fairly extensive assertion checking. This introduces significant runtime overhead. By convention, a configuration with the Fast prefix disables assertion checking.config.bootimage.compiler=opt. Unless this is set, the boot image will be compiled with the baseline compiler and virtual machine performance will be abysmal. Jikes RVM has been designed under the assumption that aggressive inlining and optimization will be applied to the VM source code.What command-line arguments should I use?For best performance we recommend the following:-X:processors=all: By default, Jikes™ RVM uses only one processor for garbage collection. Setting this option tells the garbage collection system to utilize all available processors.Set the heap size generously. We typically set the heap size to at least half the physical memory on a machine. Compiler ReplayThe compiler-replay methodology is deterministic and eliminates memory allocation and mutator variations due to non-deterministic application of the adaptive compiler. We need this latter methodology because the non-determinism of the adaptive compilation system makes it a difficult platform for detailed performance studies. For example, we cannot determine if a variation is due to the system change being studied or just a different application of the adaptive compiler. The information we record and use are hot methods and blocks information. We also record dynamic call graph with calling frequency on each edge for inlining decisions.Note that in December 2011, compiler replay was significantly improved.   The notes below apply to the post December 2011 version of replay.Here is how to use it:Generate advice.There are three kinds of advice used by the replay system, each is workload-specific (ie you should generate advice files for each benchmark):Compilation advice (.ca file).   This advice records for every compiled method which compiler (base or opt) and if opt, at which optimization level it should be compiled.  Replay compilation will not work without a compilation advice file.Edge counts (.ec file).  This advice captures edge counts generated by the execution of baseline-compiled code.   Edge counts are used by the compiler to understand which edges in the control flow graph are hot.   At the time of writing, edge counts were measured as contributing about 2% to the bottom line in terms of performance (average of DaCapo, jvm98 and jbb)Dynamic callgraph (.dc file).  This advice captures the dynamic call graph, which allows the compiler to understand the frequency with which particular call chains occur.  This is particularly useful in guiding inlining decisions.  At the time of writing the call graph contributes about 8% to the bottom line in terms of performance.One way to gather advice is to execute the benchmark multiple times under controlled settings, producing profiles at each execution.   Then establish the fastest execution among the set of runs, and choose the profiles associated with that execution as the advice files.   A common methodology is to invoke each benchmark 20 times (ie take the best invocation from a set of 20 trials), and in each invocation, run 10 iterations of the benchmark (ie the advice will then capture the warmed-up, steady state of the benchmark). When generating the advice, you will need to use the following command line arguments (typically use all six arguments, so that all three advice files are generated at each invocation):For adaptive compilation profile -X:aos:enable_advice_generation=true -X:aos:cafo=my_compiler_advice_file.ca For edge count profile -X:base:profile_edge_counters=true -X:base:profile_edge_counter_file=my_edge_counter_file.ec For dynamic call graph profile -X:aos:dcfo=my_dynamic_call_graph_file.dc -X:aos:final_report_level=2  Executing with advice.The basic model is simple.  At a nominated time in the execution of a program, all methods specified in the .ca advice file will be (re)compiled with the compiler and optimization level nominated in the advice file.  Broadly, there are two ways of initiating bulk compilation: a) by calling the method org.jikesrvm.adaptive.recompilation.BulkCompile.compileAllMethods() during execution, and b) by using the -X:aos:enable_precompile=true flag at the command line to trigger bulk compilation at boot time.  A standard methodology is to use a benchmark harness call back mechanism to call  compileAllMethods() at the end of the first iteration of the benchmark.   At the time of writing this gave performance roughly 2% faster than the 10th iteration of regular adaptive compilation.  Because precompilation occurs early, the compiler has less information about the classes, and in consequence the performance of precompilation is about 9% slower than the 10th iteration of adaptive compilation.For 'warmup' replay (where org.jikesrvm.adaptive.recompilation.BulkCompile.compileAllMethods() is called at the end of the first iteration): -X:aos:initial_compiler=base -X:aos:enable_bulk_compile=true -X:aos:enable_recompilation=false -X:aos:cafi=benchmark.ca -X:vm:edgeCounterFile=benchmark.ec -X:aos:dcfi=benchmark.dc For precompile replay (where bulk compilation occurs at boot time): -X:aos:initial_compiler=base -X:aos:enable_precompile=true -X:aos:enable_recompilation=false -X:aos:cafi=benchmark.ca -X:vm:edgeCounterFile=benchmark.ec -X:aos:dcfi=benchmark.dc Verbosity.You can alter the verbosity of the replay behavior with the flag  -X:aos:bulk_compilation_verbosity, which by default (0) is silent, but will produce more information about the recompilation with values of 1 or 2. Measuring GC performance MMTk includes a statistics subsystem and a harness mechanism for measuring its performance.  If you are using the DaCapo benchmarks, the MMTk harness can be invoked using the '-c MMTkCallback' command line option, but for other benchmarks you will need to invoke the harness by calling the static methods org.mmtk.plan.Plan.harnessBegin() org.mmtk.plan.Plan.harnessEnd() at the appropriate places.  Other command line switches that affect the collection of statistics areOptionDescription-X:gc:printPhaseStats=truePrint statistics for each mutator/gc phase during the run-X:gc:xmlStats=truePrint statistics in an XML format (as opposed to human-readable format)-X:gc:verboseThis is incompatible with MMTk's statistics system.-X:gc:variableSizeHeap=falseDisable dynamic resizing of the heapUnless you are specifically researching flexible heap sizes, it is best to run benchmarks in a fixed size heap, using a range of heap sizes to produce a curve that reflects the space-time tradeoff.  Using replay compilation and measuring the second iteration of a benchmark is a good way to produce results with low noise.There is an active debate among memory management and VM researchers about how best to measure performance, and this section is not meant to dictate or advocate any particular position, simply to describe one particular methodology.Jikes RVM is really slow! What am I doing wrong?Perhaps you are not seeing stellar Jikes™ RVM performance. If Jikes RVM as described above is not competitive product JVMs, we recommend you test your installation with the DaCapo benchmarks. We expect Jikes RVM performance to be very close to Sun's HotSpot 1.5 server running the DaCapo benchmarks. Of course, running DaCapo well does not guarantee that Jikes RVM runs all codes well.Some kinds of code will not run fast on Jikes RVM. Known issues include:Jikes RVM start-up may be slow compared to the some product JVMs.Remember that the non-adaptive configurations (-X:aos:enable_recompilation=false -X:aos:initial_compiler=opt) opt-compile every method the first time it executes. With aggressive optimization levels, opt-compiling will severely slow down the first execution of each method. For many benchmarks, it is possible to test the quality of generated code by either running for several iterations and ignoring the first, or by building a warm-up period into the code. The SPEC benchmarks already use these strategies. The adaptive configuration does not have this problem; however, we cannot stipulate that the adaptive system will compete with the product on short-running codes of a few seconds.Performance on tight loops may suffer. The Jikes RVM mechanism for safe points (thread preemption for garbage collection, on-stack-replacement, profiling, etc) relies on the insertion of a yield test on every back edge. This will hurt tight loops, including many simple microbenchmarks. We should someday alleviate this problem by strip-mining and hoisting the yield point out of hot loops, or implementing a safe point mechanism that does not require an explicit check.The load balancing in the system is naive and unfair. This can hurt some styles of codes, including bulk-synchronous parallel programs.The Jikes RVM developers wish to ensure that Jikes RVM delivers competitive performance. If you can isolate reproducible performance problems, please let us know.Stability of Jikes RVMJikes RVM is not as stable as commercial JVMs such as HotSpot or J9. Design your evaluation systems (e.g. scripts) so that they can deal with crashes and deadlocks/livelocks. The latter can be dealt with by running Jikes RVM with a timelimit. For example, if you are using Linux and shell scripts, you can use the timelimit program to terminate the Jikes RVM after a set time.  View Online · View Changes Online [Less]

Page edited by Erik Brangs - "added project status page" HomeSourceforge ProjectProject StatusNewsLicenseFAQsAcknowledgmentsResourcesCurrent ... [More] UsersPublicationsPresentationsTeaching ResourcesResearch ArchiveDocumentationUser GuideAPI DocsRegression TestsProject InformationProject OrganizationContributionsHow to HelpReporting BugsCommentsComments and constructive criticisms are welcome. View Online · View Changes Online [Less]

Page edited by Erik Brangs General project statusJikes RVM is currently the most popular platform for virtual machine research. This popularity is reflected in the ... [More] 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 supportGet DaCapo 9.12 running on the Jikes RVMPreliminary 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.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]