JikesRVM

Page edited by David Grove - "redirect to new website" The Jikes RVM web page has moved to http://www.jikesrvm.org.  Please update your bookmarks and visit our ... [More] new site.  View Online · View Changes Online [Less]

Page edited by Erik Brangs - "mention bugginess of MarkCompact, update infrastructure section to account for Jenkins setup" General project statusJikes RVM is ... [More] currently the 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?)Merge relevant changes from MRPDetailed project statusThis section provides more detailed project status information for the components. If you think an important point is missing here, please contact us via the mailing lists.BenchmarksDaCapo 2006-MR-2 runs on Jikes RVMSome benchmarks of DaCapo 9.12 workParts of SPECjvm2008 work (see RVM-484)CommunityJikes RVM has a large community in its intended audience (researchers)Core team consists wholly of volunteers: no paid developersJikes RVM is currently not packaged for any major distributionMemory ManagementGenerational Immix (the default collector) is very stableThe other collectors are reasonably stable but have some bugs (as shown by the regression tests)The MarkCompact collector is currently too buggy to useNotable 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 implementedBootimage compilation is single-threaded by default because it is too unrealiable with multiple threadsInfrastructureRegression tests are run regulary and reports are sent to the regressions mailing listCore team members have access to a Jenkins server to view test results in detailMore regression machines would be useful, in particular PowerPC machines that can be accessed by all team membersCurrently no code review tools in useSome unit tests (via JUnit) exist but most classes don't have unit tests View Online · View Changes Online [Less]

Page edited by Erik Brangs - "updated GCC compile farm information" Note: The content related to Cattack on this page is outdated. Every night regression ... [More] testing occurs for several different configurations across several different platforms. The results are uploaded to CatTrack and a report is mailed out to the regression mailing list. Look here if you are looking for how to run our automated tests.CatTrackCatTrack is a web application designed to track results of the tests over time. All the results are kept at;http://jikesrvm.anu.edu.au/cattrackIf CatTrack is done, core team members can attempt to bring it back up by doing the following: ssh [email protected] './stop.sh ; ./start.sh' Core Developer InformationCore developers may have access to a number of regression test machines provided by Australia National University. These can be used to test changes prior to committing them to the main source tree. The easiest way to test the changes is to rsyncthe source tree across. Given that most of the core developers will share a test account on these machines it is required that you rsynch the source tree into a subdirectory of the regression machines. rsync -azvLe ssh --delete --exclude '.svn' --exclude 'rvmroot/target' --exclude 'rvmroot/components' --exclude 'rvmroot/dist' $localrvmroot $machine:$remotervmroot where:localrvmroot is the directory of your local worldmachine is the ssh style machine description (eg. [email protected])remotervmroot is the directory on the test machine (eg. /home/test/irogers/rvmroot)this example shows putting your local machine as the source. You can reverse the source and target to perform the copy the other way around.Current List of Regression MachinesTo see what each machine is currently running, see the regression machine crontabsNote: The information about ANU machines in the table below is outdated.Machine NameRoleLocationOSArchitectureHardware detailsjikesrvmcatrackANULinuxx86P4jalapenoregressionANULinuxx86_64Core 2 QuadhabeneroregressionANULinuxx86_64Core 2 DuocayenneregressionANULinuxx86P4-DkumatakaregressionANULinuxx86P4-DpaprikaregressionANUOS Xx86Core 2 Duorvmppclnx64regressionANULinuxppcPower5pianoregressionWatsonLinuxppcJS21 (PPC970) 4 corespiccoloregressionWatsonAIXppcJS21 (PPC970) 4 coresPowerPC machines for developmentIf you need access to a PowerPC machine for development (as opposed to regular regression testing), you can try to ask for an account at the GCC Compile Farm.At the moment only PPC64 machines are available:MachineOSNotesgcc110Fedora 18IcedTea 7 with PPC64 JIT available in /opt/cfarm/gcc111AIX 7.1IBM Java 6 JDK and IBM Java 7 JRE availablegcc112Fedora 20IcedTea 7 with PPC64 JIT preinstalled as standard JDKSee the GCC compile farm wiki for more information. Depending on the machine you want to use, you may have to reconfigure the JDK that Ant uses. This can be done by creating an .antrc file (e.g. in your home directory).Example .antrc JAVACMD=/opt/cfarm/icedtea-2.5.3-java7-ppc64-jit/bin/java A JAVACMD entry changes the JDK that is used to run Ant. (Note: this cannot be a JRE as Ant needs a JDK.)You can use an ANT_OPTS entry to pass additional arguments to the started VM if necessary. View Online · View Changes Online [Less]

Page edited by Erik Brangs - "add GCC compile farm to acknowledgements" Jikes RVM TeamThe Jikes RVM team is responsible for creating or applying the ... [More] improvements 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 SubramanianTomoharu UgawaTom 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.Thanks to the GCC Compile Farm Project for providing access to PPC machines for free software development.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 Erik Brangs - "sketch some guidelines about error handling" Assertions in Jikes RVM and MMTkPartly for historical reasons, we use our own ... [More] built-in assertion facility rather than the one that appeared in Sun®'s JDK 1.4. All assertion checks have one of the two forms: if (VM.VerifyAssertions) VM._assert(condition) if (VM.VerifyAssertions) VM._assert(condition, message) VM.VerifyAssertions is a public static final field. The config.assertions configuration variable determines VM.VerifyAssertions' value. If config.assertions is set to none, Jikes RVM has no assertion overhead.If you use the form without a message, then the default message "vm internal error at:" will appear.If you use the form with a message the message must be a single string literal. Doing string appends in assertions can be a source of horrible performance problems when assertions are enabled (i.e. most development builds). If you want to provide a more detailed error message when the assertion fails, then you must use the following coding pattern: if (VM.VerifyAssertions && condition) { ... build message ... VM._assert(VM.NOT_REACHED, message); } An assertion failure is always followed by a stack dump.Use VM.ExtremeAssertions instead of VM.VerifyAssertions if the assertion is costly to check but generally useful. These kinds of assertions are only enabled when config.assertions is set to extreme.Use IR.SANITY_CHECK or IR.PARANOID to guard assertions that relate to the intermediate representation in the optimizing compiler.Assertions in the MMTk Test HarnessThe assert keyword may be used in the MMTk Harness.Error HandlingAll code in the system needs to detect and handle errors. If you know that your code does not handle certain situations, you should aim to write the code in way that detects these situations. The code also needs to be documented well enough so that users get a hint about the source of the problem. Keep in mind that the Jikes RVM is also used by students who may not be as familiar with the domain as researchers are.ExamplesThe code does not work at all in a certain situation, e.g. it gives incorrect results when the optimizing compiler is enabled or a certain optimization is turned on. In this case, the best approach is to detect the situation and fail fast. This can be done using assertions. You can use VM.sysFail(..) for builds without assertions if correct execution after failure is impossible.A compiler optimizations fails. The correct approach is to throw an OptimizingCompilerException (e.g. via one of the static methods provided by that class). This will lead to a hard failure when -X:vm:errorsFatal=true is set (which is the case in regression tests). In other cases, the VM will just revert to using the baseline compiler.A command line option has a limited range of values. In MMTk, the correct approach is to implement the validate() method for the option. In other places, the value of the option needs to be checked at a suitable time.  View Online · View Changes Online [Less]

Page edited by Erik Brangs - "also link to the coding conventions" 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.Getting your code contribution mergedYou should make it easy for members of the Jikes RVM team to merge your code contribution.At minimum, you must do the following:Make sure that your contribution follows our coding style and the coding conventions. 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 in your jikesrvm directory. 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 can do the following things to further 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. If you are unfamiliar with preparing patches for open source projects, take a look at this article from the Linux Foundation. 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 message Icon RVM-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]

Page edited by Erik Brangs - "clear up that we do not plan to support ppc64el; recommend to contact the team before porting to new architecture" Well-supported ... [More] platformsThe Jikes RVM version 3.1.2 runs on the following systems:IA-32 Linux®PowerPC 32 and 64 AIX™ (big endian only)PowerPC 32 and 64 Linux® (big endian)Regression tests are regularly run for these platforms.Less well-supported platformsWe also support the following operating systems:OS XSolarisWe rely on the help of the community to provide support for these platforms because we do not have any regression machines for them.Jikes RVM on Solaris may not work out-of-the-box as it does not seem to get much use.Currently unsupported platformsArchitecturesx64 is currently not supported. Jikes RVM can be built on x64 using IA-32 and 32-bit addressing (e.g. with the x86_64-linux configuration). Work on an implementation for x64 has been started.ARM architectures are not supported at all. To our knowledge, there is no publicly available code of a Jikes RVM ARM port. If you are interested in an ARM port, please open an issue in our bugtracker. You can also try to contact Jeremy Singer, who offered to mentor the GSoC 2012 project for an ARM port.There are no plans to support other architectures at this time. If you want to add support for another architecture to the mainline Jikes RVM, we urge you to contact the team via the core mailing list before starting your work.Operating SystemsWindows is currently not supported. If you are interested in support for Windows, you can take a look at Metacircular Research Platform, a fork of the Jikes RVM. It provides support for building on Windows (using the class libraries from the now retired Apache Harmony project).Other operating systems are not officially supported. View Online · View Changes Online [Less]

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

Page edited by Erik Brangs - "link to page about building the rvm instead of mentioning the required property by name" This page contains some debugging hints ... [More] for Jikes RVM. It is assumed that you are familiar with debugging techniques. If you aren't, it is advisable to read a book about the subject.Debugging Helpers provided by Jikes RVMAssertionsAll debugging should be done with assertion-enabled builds if possible. You can also try using ExtremeAssertion builds.OptionsThe Jikes RVM and MMTk provide several options to print out debugging information.If you're debugging a problem in the optimizing compiler, you can also print out the IR.You can also use the options to change the behaviour in various ways (e.g. switch off certain optimizations) if you have a suspicion about the causes of the problem.Debugger ThreadJikes has an interactive debugger that you can invoke by sending SIGQUIT to Jikes while it's running:pkill -SIGQUIT JikesRVMIn previous versions of Jikes, that stopped all threads and provided an interactive prompt, but currently it just dumps the state of the VM and continues immediately (that's a known issue: RVM-570).Debug fields in classesSeveral classes in the code base provide static boolean fields like DEBUG or VERBOSE which can be set to get more debugging information.Shutdown hooksYou can write custom shutdown hooks to dump gathered information when the VM terminates. Note that shutdown hooks won't be run if the VM is terminated via a signal (see RVM-555)Do not use the ExitMonitor from the Callbacks class because it's less reliable.TestsThe test coverage is poor at the moment. Nevertheless, if you're very lucky, one of the smaller test cases will fail. See Testing the RVM for details on how to run the tests and define your own.ToolsThere are different tools for debugging Jikes RVM:GDBThere is a limited amount of C code used to start Jikes RVM. The rvm script will start Jikes RVM using GDB (the GNU debugger) if the first argument is -gdb. Break points can be set in the C code, variables, registers can be expected in the C code. rvm -gdb <RVM args> <name of Java application> <application args> The dynamically created Java code doesn't provide GDB with the necessary symbol information for debugging. As some of the Java code is created in the boot image, it is possible to find the location of some Java methods and to break upon them. To build with debug symbols, you'll need to set the appropriate property as described in Building the RVM.Details of how to manually walk the stack in GDB can be found hererdbrdb is a debugger that was developed specifically for Jikes RVM. It allows you to inspect the bootimage. If you're running Mac OS, you can also use it to debug a running Jikes RVM.Other ToolsOther tools, such as valgrind, are occasionally useful in debugging or understanding the behaviour of JikesRVM.  The rvm script facilitates using these tools with the '-wrap' argument. rvm -wrap "<wrapper-script-and-args>" <rest of command line> For example, cachegrind can be invoked by rvm -wrap "/path/to/valgrind --tool=cachegrind" <java-command-line> The command and arguments immediately after the -wrap argument will be inserted into the script on the command line that invokes the boot image runner.  One useful variant is rvm -wrap echo <rest of command line> Specific Debugging HintsOptimizing Compiler ProblemsTo debug problems in the optimizing compiler, use a configuration whose bootimage is compiled with the baseline compiler and which contains the AOS (prototype-opt, BaseAdaptive*). Faster configurations (such as development) have the drawback of a longer bootimage compilation time which won't be amortized unless the problem occurs late.It is advisable to use -X:vm:errorsFatal=true when debugging optimizing compiler problems. This will prevent the optimizing compiler from reverting to the baseline compiler for certain kinds of errors.It is strongly recommended to run with advice file generation (see Experimental Guidelines). The produced advice files can then be used to reproduce the bug. If this step is successful, the advice files should be minimized to determine the set of methods that cause the failures. This can be done automatically (e.g. via delta debugging) or by hand.You can also switch on paranoid IR verification in IR.java. Note that this is not well tested at the moment because we don't run any regression tests with it. Use a BaseAdaptive* configuration if you switch this on (bootimage builds with the optimizing compiler and paranoid IR fail at the time of this writing).DeadlocksTo debug a deadlock, run the VM under a time limit and send SIGQUIT (to force a thread dump) a few seconds before killing the VM. On Linux, you can use the timelimit program (should be available in the repositories for Debian-based distributions).Excluding Garbage Collection problemsThe garbage collectors that are included with the Jikes RVM are generally stable. Therefore, if you see a problem that does not occur during the collection itself, it is likely not a garbage collection problem. You can exclude problems related to garbage collection by building with other collectors. For example, you can choose a collector that doesn't move objects (e.g. MarkSweep) or a collector that doesn't require write barriers (e.g. Immix instead of GenImmix). View Online · View Changes Online [Less]

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