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 Options
Non-Standard Command-Line Options
The non standard command-line options are It is generally the case that the non-standard options may change from one release to another. However, the core and memory non-standard options that are listed here don't change often.
The bulk of the non-standard options are grouped according to the subsystem that they control. The following sections list the available options in each groupSee below for details.
Core Non-Standard Command-Line Options
Print out additional lowlevel information for GC and hardware trap handling
Print out additional information while VM is booting, using verbosity level <number>
Write standard error message to <filename>
Read boot image code from <filename>
Read boot image data from <filename>
Read boot image ref map from <filename>
Load the comorg.ibm.jikesrvm.* and java.* classes from <path>
The number of processors that the garbage collector will use
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
Maximum size of heap. See above for definition of <number> and <unit>
Subsystem Non-Standard Command-Line Options
These options are all prefixed by
Should memory be protected on release?
Echo when options are set?
When printing statistics, should statistics for each gc-mutator phase be printed?
Print end-of-run statistics in XML format
Should we eagerly finish sweeping at the start of a collection
Should we print fragmentation statistics for the free list allocator?
Should we print verbose fragmentation statistics for the free list allocator?
Should we display detailed breakdown of where GC time is spent?
Should finalization be disabled?
Should reference type processing be disabled?
Should a major GC be performed when a system GC is triggered?
Should we ignore calls to java.lang.System.gc?
Should we shrink/grow the heap to adjust to application working set?
If true, all spaces are eagerly demand zero mmapped at boot time
Perform sanity checks before and after each collection?
Number of bits to use for the header cycle of mark sweep spaces
GC verbosity level
Force a collection after this much allocation
Trigger a GC if the meta data volume grows to this limit
Bound the maximum size of the nursery to this value
Fix the minimum and maximum size of the nursery to this value
Specify an address at runtime for use in debugging
Base Compiler Non-Standard Command-Line Options
Insert edge counters on all bytecode-level conditional branches
Select methods for optimized recompilation by using invocation counters
Opt Compiler Non-Standard Command-Line Options
Perform local constant propagation
Perform local copy propagation
Perform local common subexpression elimination
Perform global Array Bound Check elimination on Demand
Try to remove unnecessary monitor operations
Compile the method assuming the invokee is thread-local
Assert that any callee of this compiled method will not throw exceptions?
Eagerly compute method summaries for simple escape analysis
Eagerly compute method summaries for flow-insensitive field analysis
Perform scalar replacement of aggregates
Reorder basic blocks for improved locality and branch prediction
Reorder basic blocks using Pettis and Hansen Algo2
Inline allocation of scalars and arrays
Inline write barriers for generational collectors
Inline statically resolvable calls
Guarded inlining of non-final virtual calls
Speculatively inline non-final interface calls
CFG splitting to create hot traces based on static heuristics
Eliminate redundant conditional branches
Pre-existence based inlining
Should SSA form be constructed on the HIR?
Should we perform redundant load elimination during SSA pass?
Should we coalesce move instructions after leaving SSA?
Should we try to fold expressions with constants in SSA form?
Split live ranges using LIR SSA pass?
Perform global code placement
Perform global code placement
Perform noisy global code placement
Assume PEIs do not throw or state is not observable
Turn whiles into untils
Store liveness for handlers to improve dependence graph at PEIs
Perform prepass instruction scheduling
Should all checkcast operations be (unsafely) eliminated?
Should all checkstore operations be (unsafely) eliminated?
Should all bounds check operations be (unsafely) eliminated?
Should all null check operations be (unsafely) eliminated?
Should all synchronization operations be (unsafely) eliminated?
Should all yield points be (unsafely) eliminated?
Should cache flush instructions (PowerPC SYNC/ISYNC) be omitted? NOTE: Cannot be correctly changed via the command line!
Should we constrain optimizations by enforcing reads-kill?
Should we treat all monitorenter/monitorexit bytecodes as nops?
Should we dump out compile-time statistics for basic blocks?
Should all patch point be (unsafely) eliminated (at initial HIR)?
Perform code transformation to sample instrumentation code.
When performing inst. sampling, should it be done without duplicating code?
Should there be one CBS counter per processor for SMP performance?
Should yieldpoints be removed from the checking code (requires finite sample interval).
Static inlining heuristic: Upper bound on callee size
Static inlining heuristic: Upper bound on depth of inlining
Static inlining heuristic: Always inline callees of this size or smaller
Static inlining heuristic: If root method is already this big, then only inline trivial methods
Adaptive inlining heuristic: Upper bound on callee size
Adaptive inlining heuristc: Minimum fraction of callsite distribution for guarded inlining of a callee
Input file of edge counter profile data
Selection of guard mechanism for inlined virtual calls that cannot be statically bound
Selection of strictness level for floating point computations
Exclude methods from being opt compiled
Unroll loops. Duplicates the loop body 2^n times.
How many extra instructions will we insert in order to remove a conditional branch?
How many rounds of redundant load elimination will we attempt?
Read allocation advice attributes for all classes from this file
How to compute block and edge frequencies?
Selection of spilling heuristic
Cumulative threshold which defines the set of infrequent basic blocks
Threshold at which a conditional branch is considered to be skewed
Only print IR compiled above this level
Adaptive System Non-Standard Command-Line Options
Should the adaptive system recompile hot methods?
Do we need to generate advice file?
Should the adaptive system precompile all methods given in the advice file before the user thread is started?
Should the adaptive system use the pseudo-adaptive system that solely relies on the advice file?
Should profile data be gathered and reported at the end of the run?
Should we use adaptive feedback-directed inlining?
Should AOS exit when the controller clock reaches early_exit_value?
Should AOS promote baseline-compiled methods to opt?
Should recompilation be done on a background thread or on next invocation?
Insert instrumentation in opt recompiled code to count yieldpoints executed?
Insert intrusive method counters in opt recompiled code?
Insert counters on all instructions in opt recompiled code?
Enable easy insertion of (debugging) counters in opt recompiled code.
Report stats related to timer interrupts and AOS listeners on exit.
Disable the ability for an app to request all methods to be recompiled.
How many timer ticks of method samples to take before reporting method hotness to controller.
Selection of initial compiler.
Selection of mechanism for identifying methods for optimizing recompilation.
What triggers us to take a method sample?
What triggers us to take a method sample?
Name of log file.
Name of advice file.
Name of dynamic call graph file.
Name of compiler DNA file (no name ==> use default DNA). Discussed in a comment at the head of VM_CompilerDNA.java.
File containing information about the methods to Opt compile.
File containing information about the hot call sites.
Control amount of event logging (larger ==> more).
Control amount of info reported on exit (larger ==> more).
After how many clock ticks should we decay.
What factor should we decay call graph edges hotness by.
After how many timer interrupts do we update the weights in the dynamic call graph?
Initial edge weight of call graph is set to ai_seed_multiplier * (1/ai_control_point).
Name of offline inline plan to be read and used for inlining.
Value of controller clock at which AOS should exit if early_exit is true.
Invocation count at which a baseline compiled method should be recompiled.
Opt level for recompilation in invocation count based system.
What is the sample interval for counter-based sampling.
What percentage of the total weight of the dcg demarcates warm/hot edges.
The maximum optimization level to enable.
Virtual Machine Non-Standard Command-Line Options
Time all compilations and report on exit.
Time all compilation sub-phases and report on exit.
Stack traces to consist of VM and application frames.
Dump a stack trace (via VM.syswrite) upon exit.
More detailed tracing then -verbose:class.
Exit when non-fatal errors are detected; used for regression testing.
If we get deeper than this in one of the System Trouble functions, try to die.
Timer interrupt scheduling quantum in ms.
Scheduling quantum = interruptQuantum * schedulingMultiplier.
Trace actions taken by thread scheduling.
Trace every nth time a stack trace is created.
Input file of edge counter profile data.
How many CBS call samples (Prologue/Epilogue) should we take per time tick.
Stride between each CBS call sample (Prologue/Epilogue) within a sampling window.
How many CBS method samples (any yieldpoint) should we take per time tick.
Stride between each CBS method sample (any yieldpoint) within a sampling window.
Count, and report, the number of thread state transitions. This works better on IA32 than on PPC at the moment.
Force all threads to run on one CPU. The argument specifies which CPU (starting from 0).
The other non-standard command line options are not listed here because they will change from time to time. To get a current list of these options, you can do the following:
To find out which subsystems are available in the image you're using:
To get information about the options for a specific subsystem (e.g. the garbage collection subsystem)
To find out the current values of the options for a specific subystem (e.g. the optimizing compiler subsystem)
Running Jikes RVM with valgrind