| Age | Commit message (Collapse) | Author |
|---|
|
Following this version bump:
https://github.com/mono/mono/commit/069cea3712a5bd4959e505260cdc4a0c37861e77
(Also add a note to configure.ac as a hint until
someone comes up with a way to sync man/mono.1's
version automatically.)
|
|
|
|
- Back out MONO_PROFILER_LIB_DIR change
- Profiler loading traces should use log mask “dll” not “asm”
- mono_dl_open_runtime_lib should preempt standard paths when loading
profiler
- mono_dl_open_runtime_lib should check in profiler library directory
- mono_dl_open_runtime_lib contained a memory leak
- With above changes, ptestrunner.pl can remove some environment
massaging
|
|
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.
|
|
Various cleanups on profiler
3 commits:
Assist on profiler module loading
- Add a MONO_PROFILER_LIB_DIR from which profiler modules are
dynamically loading, in case it is not the normal library path
- Add information about profiler loading to mono_trace
Comments and clarity in proflog.c
- Add comments on structures
- Rename 'data' and 'data_end' to 'cursor' and 'buf_end' in LogBuffer/StatsBuffer as the old names were confusing
- Add new assert when processing samples
Improve a safety check when writing data into StatBuffer
- The safety check should occur such that if the new value for
StatBuffer::cursor is beyond the bounds of the StatBuffer, the cursor
is not updated.
|
|
- Add a MONO_PROFILER_LIB_DIR from which custom profilers are
dynamically loaded, in case it is not the normal library path
- Modify mono/profiler make check to use MONO_PROFILER_LIB_DIR
(this fixes a bug where it would sometimes load the wrong profiler)
- Add information about profiler loading to mono_trace
|
|
variable.
|
|
Option disables a compiler optimization that omits framepointers from the stack.
|
|
|
|
This commit moves mono_trace to a header file so that all the
calls are inlined, avoiding one function call at the small expense
of binary size.
|
|
|
|
|
|
Automatic optimization bug bisector.
|
|
|
|
|
|
|
|
|
|
fixes #28693
|
|
|
|
options.
|
|
Also add missing man page entry.
|
|
The new options were added by the following commits:
align-small-structs f7b9bb3bf001049687c235df36d9af3c10026684
arm-use-fallback-tls 421fa312a54f1f31dcecec3cc963c06b978bd7cc
debug-domain-unload 3c0c5f862432e3ce68f16e7aa79b6e5e96ab4510
gen-compact-seq-points ab392debf4ca12751c4dd05dd3c02374bdcfabb6
partial-sharing 1cab7b05353bccb8d7ef160448ffcde827e99386
single-imm-size 9e0d8418720ebd43251ae6ad45f5700b298da808
soft-breakpoints a2c629efe29741d91ac87dcb71c23fd4510c6a12
suspend-on-exception fcbf89d2adfd9bec75db35ad5af82556988de812
suspend-on-unhandled eb8be6f65161ef7b84debe8b232b025b1abe7ae4
|
|
|
|
|
|
|
|
|
|
and the code supporting them.
|
|
|
|
|
|
We cannot start threads during stop-the-world pauses (some thread APIs,
including pthreads, can deadlock), and we want to do marking and sweeping
with the same threads. This new thread pool facility will allow that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Even though the old links still work, we can save everyone an unnecessary redirect by using the new links.
|
|
|
|
Use the new MONO_GC_DEBUG option "nursery-canaries" to suffix each nursery object with a canary (guard) word, which is checked on each minor collection. Can be used to detect/debug
heap corruption issues.
Adding canaries to LOS is also easy if wanted - not sure about major heap.
|
|
This was almost completely untested and performance was
erratic.
|
|
It's not well-tested, not widely used, we can surpass its speed with
upcoming improvements and we won't put those into the fixed
configuration because it's too much of a diversion.
|
|
With the debug policy, we do clear at TLAB creation, but at GC time, whenever
we would clear with `clear-at-gc`, instead of not clearing, we fill with 0xff.
|
|
|
|
Tha previous behaviour of MONO_PATH for relative paths (that implied
using the paths as relative to the current directory when loading
assemblies) was not yet documented and led to some failures when
executing tests.
In order to fix the failures, a new behaviour has been introduced:
relative paths are resolved at launch time, so that the folders which
are examined when loading assemblies do not depend on the current path
of the program.
This patchset is released under the MIT license.
|
|
cdecl/stdcall mismatches.
|
|
Also a bit of cleanup in the hwcap code.
|
|
1. MONO_THREADS_PER_CPU affects ThreadPool min threads rather than max threads
2. Effect is MONO_THREADS_PER_CPU * cpu_cores, there is no +20
3. Default is 1, not 10
|
|
|
|
[ThreadPool] Allow heavier initialization when using --server flag
|
|
Create on demand up to min_threads to avoid startup penalty, avoiding
throttling of threadpool worker thread creation (for now, using
a --server flag) at initialization.
When throttling happens, operations such as parallel https requests were
slowed down significantly due to all of the threads created in order
to complete the SSL operations.
Based on @kamalaboulhosn's patch (https://github.com/mono/mono/pull/640/files)
|
