.\"
.\" mono manual page.
-.\" (C) 2003 Ximian, Inc.
-.\" (C) 2004-2005 Novell, Inc.
+.\" Copyright 2003 Ximian, Inc.
+.\" Copyright 2004-2009 Novell, Inc.
.\" Author:
.\" Miguel de Icaza (miguel@gnu.org)
.\"
-.TH Mono "Mono 2.2"
+.TH Mono "Mono 2.5"
.SH NAME
mono \- Mono's ECMA-CLI native code generator (Just-in-Time and Ahead-of-Time)
.SH SYNOPSIS
.B all,
a heap snapshot is taken at each collection.
.PP
-If the value is signal name or a number (one of SIGUSR1, SIGUSR2 and
-SIGPROF, remembering that SIGPROF is not compatible with the
-statistical profiler), every time the application receives this signal
-a garbage collection is forced and a snapshot is taken. The natural way
-to take a heap snapshot is then using the kill command to deliver the
-appropriate signal to the application.
+If the value is an integer
+.B n,
+a snapshot will be taken at the first
+.B n
+collections (like setting
+.B gcd=n
+);
+.PP
+If no additional argument is given to the heap option, the only way to take
+heap snapshots is to requeste them using the runtime socket based command
+interface described below (see "Profiler activity control").
.PP
Heap profiling also enables full allocation profiling (with call
stacks), and each allocation can be related to its corresponding
states the number of snapshots that must be dumped (since the application
starts). Zero means no dumps at all, -1 means dump at all collections.
.TP
-\fIgc-commands=FILE\fR, \fIgc-c=FILE\fR or \fIgcc=FILE\fR
-specify a "command file". The file must contain an integer value in ASCII
-form, and the profiler will stat it at every collection.
-If it has been modified it will interpret its contents as a \fIgcd=N\fR
-option value, and dump the required number of snapshots from that moment
-onwards.
-If the file is present at application startup it takes precedence over an
-eventual \fIgcd=N\fR option.
-.TP
These options exist because it can happen that the user wants to investigate
-what happens during collections but without forcing a collection using a
-signal, because forcing a collection alters the program behavior.
+what happens during collections but without forcing a collection using the
+command interface, because forcing a collection alters the program behavior.
Of course it is possible to simply take a snapshot at every collection, but
in some workloads this is could not be feasible (too much data).
So we have this "garbage collection dumps" counter to control how many
.TP
\fIstart-disabled\fR or \fIsd\fR: start with the profiler inactive.
.TP
-\fItoggle-signal=<SIGNAL>\fR or \fIts=<SIGNAL>\fR (where <SIGNAL>
-is one of SIGUSR1, SIGUSR2 or SIGPROF): Choose a signal that will be used to
-toggle the profiler activity on and off. This way you can decide to profile
-only portions of the applicatopn lifetime (for instance, you can decide to
-avoid profiling an initial setup phase using \fIsd\fR, and enable the
-profiler later delivering the signal to the application).
-.TP
\fIforce-accurate-timer\fR (or \fIfac\fR): the profiler by default uses
rtdsc to acquire timestamps for frequent events, but this can be imprecise;
using this option you force the use of "gettimeofday" at every event, which
is more accurate but much slower.
+.TP
+\fIcommand-port=port\fR or \fIcp=port\fR (where port is an integer between
+1024 nd 65535):
+Choose a TCP port where the profiler will listen for user commands.
+The protocol is ASCII based and line oriented (one line per command), and the
+profiler answers with one line containing either "OK" or "ERROR" to each
+received command.
+.PP
+The user can telnet to this port and give commands manually, or a GUI can
+use this facility to control the profiler at runtime.
+.PP
+The available commands are:
+.TP
+\fIenable\fR: Enables the profiler.
+.TP
+\fIdisable\fR: Disables the profiler.
+.TP
+\fIheap-snapshot\fR: Takes a heap snapshot now (forces a full garbage collection).
+.TP
+\fIheap-snapshot-counter=arg\fR: Set the counter of the next heap snapshots
+that must be taken, where arg can be "all" (take a snapshot at every
+collection), "none" (do not take snapshots), or an integer "n" (take a heap
+snapshot for the next "n" collections).
.ne
.RE
.PP
and the application might crash or terminate at any given point
afterwards.
.PP
-The \fB--debug=casts\FR option can be used to get more detailed
+The \fB--debug=casts\fR option can be used to get more detailed
information for Invalid Cast operations, it will provide information
about the types involved.
.PP
Turns off the garbage collection in Mono. This should be only used
for debugging purposes
.TP
+\fBLVM_COUNT\fR
+When Mono is compiled with LLVM support, this instructs the runtime to
+stop using LLVM after the specified number of methods are JITed.
+This is a tool used in diagnostics to help isolate problems in the
+code generation backend. For example \fBLLVM_COUNT=10\fR would only
+compile 10 methods with LLVM and then switch to the Mono JIT engine.
+\fBLLVM_COUNT=0\fR would disable the LLVM engine altogether.
+.TP
\fBMONO_AOT_CACHE\fR
If set, this variable will instruct Mono to ahead-of-time compile new
assemblies on demand and store the result into a cache in
.fi
If you are using mod_mono to host your web applications, you can use
the
-.B MonoSetEnv
-directive, like this:
+.B MonoIOMAP
+directive instead, like this:
.nf
- MonoSetEnv MONO_IOMAP=all
+ MonoIOMAP <appalias> all
.fi
+See mod_mono(8) for more details.
.TP
\fBMONO_MANAGED_WATCHER\fR
If set to "disabled", System.IO.FileSystemWatcher will use a file watcher
libraries side-by-side with the main executable.
.Sp
For a complete description of recommended practices for application
-deployment, see the
-http://www.mono-project.com/Guidelines:Application_Deployment page.
+deployment, see
+http://www.mono-project.com/Guidelines:Application_Deployment
.TP
\fBMONO_RTC\fR
Experimental RTC support in the statistical profiler: if the user has
above locations. If you don't want the mapping to be performed you can set this
variable in your environment before starting the application and no action will
be taken.
+.TP
+\fBMONO_MESSAGING_PROVIDER\fR
+Mono supports a plugin model for its implementation of System.Messaging making
+it possible to support a variety of messaging implementations (e.g. AMQP, ActiveMQ).
+To specify which messaging implementation is to be used the evironement variable
+needs to be set to the full class name for the provider. E.g. to use the RabbitMQ based
+AMQP implementation the variable should be set to:
+
+.nf
+Mono.Messaging.RabbitMQ.RabbitMQMessagingProvider,Mono.Messaging.RabbitMQ
.SH ENVIRONMENT VARIABLES FOR DEBUGGING
.TP
\fBMONO_ASPNET_NODELETE\fR
http://www.mono-project.com
.SH SEE ALSO
.PP
-certmgr(1), csharp(1), mcs(1), mdb(1), monocov(1), monodis(1), mono-config(5), mozroots(1), xsp(1).
+certmgr(1), csharp(1), mcs(1), mdb(1), monocov(1), monodis(1),
+mono-config(5), mozroots(1), pdb2mdb(1), xsp(1), mod_mono(8).
.PP
For more information on AOT:
http://www.mono-project.com/AOT
projects / mono.git / blobdiff