diff options
author | Alex Rønne Petersen <alexrp@xamarin.com> | 2016-03-20 05:08:42 +0300 |
---|---|---|
committer | Alex Rønne Petersen <alexrp@xamarin.com> | 2016-04-01 04:53:10 +0300 |
commit | 2538a352f4ff2bb2636491aa1bb82ce4d03ab80f (patch) | |
tree | 3f3b40fee4425af83623e9363e6d864fb332d809 /man/mono.1 | |
parent | c642d898a4345554751f163ed3714fd2bf012fbe (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/mono.1')
-rw-r--r-- | man/mono.1 | 19 |
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 |