Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/mono/mono.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/man
diff options
context:
space:
mode:
authorAlex Rønne Petersen <alexrp@xamarin.com>2016-03-20 05:08:42 +0300
committerAlex Rønne Petersen <alexrp@xamarin.com>2016-04-01 04:53:10 +0300
commit2538a352f4ff2bb2636491aa1bb82ce4d03ab80f (patch)
tree3f3b40fee4425af83623e9363e6d864fb332d809 /man
parentc642d898a4345554751f163ed3714fd2bf012fbe (diff)
[profiler] Use a background thread to send out sampling signals.
Previously, when using an interval timer, the initial profiling signal could be delivered to *any* thread in the process. This is not normally a problem, but if the signaled thread has not even finished its initialization inside libc, it can happen that it hasn't even set up thread-local storage yet. We then blow up spectacularly when trying to back up errno in the SIGPROF signal handler, as it's a TLS variable. Even the SIGSEGV handler blows up immediately after as it can't access JIT TLS data. Since there appears to be no reliable and portable way for a library like Mono to control which exact thread gets the initial timer signal, instead switch to using a background thread that uses a high-resolution sleep and attempts to switch itself to real time scheduling if possible. This way, we have full control over which threads we send SIGPROF to, letting us avoid any threads which aren't in a 'good' state for profiling. This commit also gets rid of the multiplexing that was going on in the SIGPROF signal handler, since we now send out the signals from a background thread. As this was the only use of the async job API, that API has been removed. This indirectly fixes the signal storming issue that sometimes popped up, where for some reason multiple threads would think that they're the initiating thread, resulting in way too many signals going out. A nice side-effect of doing the signaling ourselves is that we can now use real-time signals on systems that have them (e.g. Linux), resulting in a nearly 100% signal delivery rate in all cases. Previously, we would lose a tremendous amount of signals when an application was under heavy load.
Diffstat (limited to 'man')
-rw-r--r--man/mono.119
1 files changed, 0 insertions, 19 deletions
diff --git a/man/mono.1 b/man/mono.1
index 7eb8055fb4f..f0df69e7e01 100644
--- a/man/mono.1
+++ b/man/mono.1
@@ -1513,26 +1513,7 @@ http://www.mono-project.com/docs/getting-started/application-deployment/
Provides a search path to the runtime where to look for custom profilers. See the
section "CUSTOM PROFILERS" above for more information. Custom profilers will be
searched for in the MONO_PROFILER_LIB_DIR path before the standard library paths.
-
.TP
-\fBMONO_RTC\fR
-Experimental RTC support in the statistical profiler: if the user has
-the permission, more accurate statistics are gathered. The MONO_RTC
-value must be restricted to what the Linux rtc allows: power of two
-from 64 to 8192 Hz. To enable higher frequencies like 4096 Hz, run as root:
-.nf
-
- echo 4096 > /proc/sys/dev/rtc/max-user-freq
-
-.fi
-.Sp
-For example:
-.nf
-
- MONO_RTC=4096 mono --profiler=default:stat program.exe
-
-.fi
-.TP
\fBMONO_SHARED_DIR\fR
If set its the directory where the ".wapi" handle state is stored.
This is the directory where the Windows I/O Emulation layer stores its