.\"
.\" 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)
.\"
.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), a garbage collection is forced and a snapshot
-is taken every time the signal is received.
+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.
.PP
Heap profiling also enables full allocation profiling (with call
stacks), and each allocation can be related to its corresponding
objects of a given class allocated by a given method and still live at
a given collection, and then find all objects referencing them".
.PP
-The heap shot log can be further customized with the following
-options:
+This kind of heap snapshot analysis is performed using the mprof-heap-viewer(1)
+application.
+.PP
+The number of heap snapshots taken (and the moment in which they are taken)
+can be further customized with the following options:
.TP
\fIgc-dumps=N\fR, \fIgc-d=N\fR, \fIgcd=N\fR
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-signal=<signal>\fR, \fIgc-s\fR or \fIgcs\fR
-(where <signal> is one of "SIGUSR1", "SIGUSR2", or "SIGPROF")
-specifies a signal that will immediately trigger a collection and a dump.
-.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.
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.
+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
+snapshots to take.
.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
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).
.PP
For more information on AOT:
http://www.mono-project.com/AOT
projects / mono.git / blobdiff