Miguel de Icaza runtime

While Mono has had support for SIMD instructions in the form of the Mono.SIMD API, this API was limited to run on x86 platforms.

.NET introduced the System.Numeric.Vectors API which sports a more general design that adapts to the SIMD registers available on different platforms.

The master branch of Mono now treats the various Vector operations as runtime intrinsics, so they are hardware accelerated. They are supported by both the Mono JIT compiler on x86-x64 platforms and via LLVM’s optimizating compiler on x86-64 and every other Mono/LLVM supported platform.

We would love to see you try it and share your experience with us.

Miguel de Icaza plans

Mono’s use of Reference Source Code

Since the first release of the .NET open source code, the Mono project has been integrating the published Reference Source code into Mono.

We have been using the Reference Source code instead of the CoreFX, as Mono implements a larger surface area than what is exposed in there - Mono implements the .NET Desktop API.

Integrating the code sometimes is easy, we replace the code in Mono with the reference source code. When the code is not exactly portable, we need to make it portable and either write missing code, or integrate some of the work that we did in Mono, with the code that existed in .NET. There are some cases where porting the code is just too complicated, and we have not been able to do the work.

We keep track of the major items in Trello.

Originally, we forked the reference source code and kept a branch with our code, but it was too large of an external dependency and it was also a module that was quite static. So recently, we started copying the code that we needed directly into Mono.

While this has worked fine for a while, the .NET Reference Source is only updated when a major .NET release takes place, and it tracks the version of .NET that ships along with Windows. This means that we are missing on many of the great optimizations and improvements that are happening as part of .NET Core.

The optimizations and fine tuning typically take place in two places, work that goes into mscorlib.dll is maintained in the coreclr module while the higher level frameworks are maintained in the corefx module.

A New Approach

Many of the APIs that were originally removed from CoreFX are now being added back, so we can start to consider switching away from referencesource and into CoreFX.

After discussing with the .NET Core team, we came up with a better approach for the long-term maintenance of the shared code.

The .NET team has now setup a new repository where the cleaned up and optimized version of mscorlib.dll will live in the corert module.

What we will do is submodule both CoreRT and CoreFX and replace our manually copied code from the Reference Source with code from CoreRT and CoreFX.

The twist is that for scenarios where Mono’s API surface is larger, we will contribute changes back to CoreRT/CoreFX where we either add support for the larger API surface, or we make the API pluggable (likely with a tasteful use of the partial modifier).

One open issue is that Mono has historically used a single set of framework libraries (like mscorlib.dll, System.dll etc.) that work across Linux, MacOS, Unix and Windows and they dynamically detect how to behave based on the platform. This is useful on scenarios where you want to bootstrap work in one platform by using another one, as the framework libraries are identical.

CoreFX takes a different approach, the libraries are tied to a particular platform flavor.

This means that some of the work that we will have to do will involve either adjusting the CoreFX code to work in the way that Mono works, or give up on our tradition of having the same assemblies work across all platforms.

Rodrigo Kumpera and Bernhard Urban runtime

When someone says multi-core, we unconsciously think SMP. That worked out well for us until recently when ARM announced big.LITTLE. ARM’s big.LITTLE architecture is the first mass produced AMP architecture and as we’ll see next, it raises the bar for how hard multi-core programing is.

A tale of an impossible bug

It all started with a bug report against a phone with such a CPU, the Exynos chipset used on Samsung phones in Europe. Apps created with our software were dying with SIGILL at all completely random places. Nothing could reasonably explain what was happening, and the crash was happening with valid instructions. This immediately made us suspect bad instruction cache flushing.

After reviewing all JIT code around cache flushing we were sure that we were calling __clear_cache properly. That lead us to look around for how other virtual machines or compilers do cache flushing on ARM64, and we found out about some related errata on the Cortex A53. ARM’s description of those issues is both cryptic and vague, but we tried the workaround anyways. No luck there.

Next we went with the other usual suspects. A lying signal handler? Nope. Funky userspace CPU emulation? No. Broken libc implementation? Nice try. Faulty hardware? We reproduced it on multiple devices. Bad luck or karma? Yes!

Some of us could not sleep with such amazing puzzle in front of us and kept staring at memory dumps around failure sites. And there was this funny thing: the fault address was always on the third or fourth line of the memory dumps.


This was our only clue, and there are no coincidences when it comes to this sort of byzantine bug. Our memory dumps were of 16 bytes per line and the SIGILL would always happen to be somewhere between 0x40-0x7f or 0xc0-0xff. We aligned the memory dump to help verify whether the code allocator was doing something funky:

$ grep SIGILL *.log
custom_01.log:E/mono           (13964): SIGILL at ip=0x0000007f4f15e8d0
custom_02.log:E/mono           (13088): SIGILL at ip=0x0000007f8ff76cc0
custom_03.log:E/mono           (12824): SIGILL at ip=0x0000007f68e93c70
custom_04.log:E/mono           (12876): SIGILL at ip=0x0000007f4b3d55f0
custom_05.log:E/mono           (13008): SIGILL at ip=0x0000007f8df1e8d0
custom_06.log:E/mono           (14093): SIGILL at ip=0x0000007f6c21edf0

With that we came to our first good hypothesis: Bad cache flushing was happening only on the upper 64 bytes of every 128-byte block. Those numbers, if you deal with low level programming, immediately remind you of cache line sizes. And that is where it all started to make sense.

Here is a pseudo version of how libgcc does cache flushing on arm64:

void __clear_cache (char *address, size_t size)
    static int cache_line_size = 0;
    if (!cache_line_size)
        cache_line_size = get_current_cpu_cache_line_size ();

    for (int i = 0; i < size; i += cache_line_size)
        flush_cache_line (address + i);

In the above pseudo-code get_current_cpu_cache_line_size is a CPU instruction that returns the line size of its caches, and flush_cache_line flushes the cache line that contains the supplied address.

At that point we were using our own version of this function, so we instrumented it to print the cache line size as returned by the CPU and, lo and behold, it printed both 128 and 64. We double verified that this was indeed the case. So we went to see that particular CPU manual and it turns out that the big core has a 128 bytes cache line but on the LITTLE core it is only 64 bytes for the instruction cache.

So what was happening is that __clear_cache would be called first on a big core and cache 128 as the instruction cache line size. Later it would be called on one of the LITTLE cores and would skip every other cache line when flushing. It doesn’t get simpler than that. We removed the caching and it all worked.


Some ARM big.LITTLE CPUs can have cores with different cache line sizes, and pretty much no code out there is ready to deal with it as they assume all cores to be symmetrical.

Worse, not even the ARM ISA is ready for this. An astute reader might realize that computing the cache line on every invocation is not enough for user space code: It can happen that a process gets scheduled on a different CPU while executing the __clear_cache function with a certain cache line size, where it might not be valid anymore. Therefore, we have to try to figure out a global minimum of the cache line sizes across all CPUs. Here is our fix for Mono: Pull Request. Other projects adopted our fix as well already: Dolphin and PPSSPP.

Alex Rønne Petersen profiler

This is the first in a series of posts I’ll be writing on the work we’ve been doing to improve the stability of Mono’s log profiler. All improvements detailed in these blog posts are included in Mono 4.6.0, featuring version 1.0 of the profiler. Refer to the release notes for the full list of changes and fixes.

The problem we’ll be looking at today is a crash that arose when running the profiler in sampling mode (i.e. mono --profile=log:sample foo.exe) together with the SGen garbage collector.

The Problem

SGen uses so-called managed allocators to perform very fast allocations from the nursery (generation 0). These managed allocators are generated by the Mono runtime and contain specialized code for allocating particular kinds of types (small objects, strings, arrays, etc). One important invariant that managed allocators rely on is that a garbage collection absolutely cannot proceed if any suspended thread was executing a managed allocator at the time it was suspended. This allows the managed allocators to do their thing without taking the global GC lock, which is a huge performance win for multithreaded programs. Should this invariant be broken, however, the state of the managed heap is essentially undefined and all sorts of bad things will happen when the GC proceeds to doing scanning and sweeping.

Unfortunately, the way that sampling works caused this invariant to be broken. When the profiler is running in sampling mode, it periodically sends out a signal (e.g. SIGPROF) whose signal handler will collect a managed stack trace for the target thread and write it as an event to the log file. There’s nothing actually wrong with this. However, the way that SGen checks whether a thread is currently executing a managed allocator is as follows (simplified a bit from the actual source code):

static gboolean
is_ip_in_managed_allocator (MonoDomain *domain, gpointer ip)
     * ip is the instruction pointer of the thread, as obtained by the STW
     * machinery when it temporarily suspends the thread.

    MonoJitInfo *ji = mono_jit_info_table_find_internal (domain, ip, FALSE, FALSE);

    if (!ji)
        return FALSE;

    MonoMethod *m = mono_jit_info_get_method (ji);

    return sgen_is_managed_allocator (m);

To understand why this code is problematic, we must first take a look at how signal delivery works on POSIX systems. By default, a signal can be delivered while another signal is still being handled. For example, if your program has two separate signal handlers for SIGUSR1 and SIGUSR2, both of which simply do while (1); to spin forever, and you send SIGUSR1 followed by SIGUSR2 to your program, you’ll see a stack trace looking something like this:

(gdb) bt
#0  0x0000000000400564 in sigusr2_signal_handler ()
#1  <signal handler called>
#2  0x0000000000400553 in sigusr1_signal_handler ()
#3  <signal handler called>
#4  0x00000000004005d3 in main ()

Unsurprisingly, if we print the instruction pointer, we’ll find that it’s pointing into the most recently called signal handler:

(gdb) p $pc
$1 = (void (*)()) 0x400564 <sigusr2_signal_handler+15>

This matters because SGen uses a signal of its own to suspend threads in its STW machinery. So that means we have two signals in play: The sampling signal used by the profiler, and the suspend signal used by SGen. Both signals can arrive at any point, including while the other is being handled. In an allocation-heavy program, we could very easily see a stack looking something like this:

#0 suspend_signal_handler ()
#1 <signal handler called>
#2 profiler_signal_handler ()
#3 <signal handler called>
#4 AllocSmall ()

(Here, AllocSmall is the managed allocator.)

Under normal (non-profiling) circumstances, it would look like this:

#0 suspend_signal_handler ()
#1 <signal handler called>
#2 AllocSmall ()

Mono installs signal handlers using the sigaction function with the SA_SIGINFO flag. This means that the signal handler will receive a bunch of information in its second and third arguments. One piece of that information is the instruction pointer of the thread before the signal handler was invoked. This is the instruction pointer that is passed to the is_ip_in_managed_allocator function. So when we’re profiling, we pass an instruction pointer that points into the middle of profiler_signal_handler, while in the normal case, we pass an instruction pointer that points into AllocSmall as expected.

So now the problem is clear: In the normal case, SGen detects that the thread is executing a managed allocator, and therefore waits for it to finish executing before truly suspending the thread. But in the profiling case, SGen thinks that the thread is just executing any arbitrary, unimportant code that it can go right ahead and suspend, even though we know for a fact (from inspecting the stack in GDB) that it is actually in the middle of executing a managed allocator.

When this situation arises, SGen will go right ahead and perform a full garbage collection, even though it’ll see an inconsistent managed heap as a result of the managed allocator being in the middle of modifying the heap. Entire books could be written about the incorrect behavior that could result from this under different circumstances, but long story short, your program would crash in random ways.

Potential Solutions

At first glance, this didn’t seem like a hard problem to solve. My initial thought was to set up the signal handler for SIGPROF in such a way that the GC suspend signal would be blocked while the handler is executing. Thing is, this would’ve actually fixed the problem, but not in a general way. After all, who’s to say that some other signal couldn’t come along and trigger this problem? For example, a programmer might P/Invoke some native code that sets up a signal handler for some arbitrary purpose. The user would then want to send that signal to the Mono process and not have things break left and right. We can’t reasonably ask every Mono user to block the GC suspend signal in any signal handlers they might set up, directly or indirectly. Even if we could, it isn’t a good idea, as we really want the GC suspend signal to arrive in a timely fashion so that the STW process doesn’t take too long (resulting in long pause times).

OK, so that idea wasn’t really gonna work. Another idea that we considered was to unwind the stack of the suspended thread to see if any stack frame matches a managed allocator. This would solve the problem and would work for any kind of signal that might arrive before a GC suspend signal. Unfortunately, unwinding the stack of a suspended thread is not particularly easy, and it can’t be done in a portable way at all. Also, stack unwinding is not exactly a cheap affair, and the last thing we want is to make the STW machinery slower - nobody wants longer pause times.

Finally, there was the nuclear option: Disable managed allocators completely when running the profiler in sampling mode. Sure, it would make this problem go away, but as with the first idea, SGen would still be susceptible to this problem with other kinds of signals when running normally. More importantly, this would result in misleading profiles since the program would spend more time in the native SGen allocation functions than it would have in the managed allocators when not profiling.

None of the above are really viable solutions.

The Fix

Conveniently, SGen has this feature called critical regions. They’re not quite what you might think - they have nothing to do with mutexes. Let’s take a look at how SGen allocates a System.String in the native allocation functions:

MonoString *
mono_gc_alloc_string (MonoVTable *vtable, size_t size, gint32 len)


    MonoString *str = sgen_try_alloc_obj_nolock (vtable, size);

    if (str)
        str->length = len;


    if (!str) {

        str = sgen_alloc_obj_nolock (vtable, size);

        if (str)
            str->length = len;


    return str;

The actual allocation logic (in sgen_try_alloc_obj_nolock and sgen_alloc_obj_nolock) is unimportant. The important bits are TLAB_ACCESS_INIT, ENTER_CRITICAL_REGION, and EXIT_CRITICAL_REGION. These macros are defined as follows:

#define TLAB_ACCESS_INIT SgenThreadInfo *__thread_info__ = mono_native_tls_get_value (thread_info_key)
#define IN_CRITICAL_REGION (__thread_info__->client_info.in_critical_region)
#define ENTER_CRITICAL_REGION do { mono_atomic_store_acquire (&IN_CRITICAL_REGION, 1); } while (0)
#define EXIT_CRITICAL_REGION do { mono_atomic_store_release (&IN_CRITICAL_REGION, 0); } while (0)

As you can see, they simply set a variable on the current thread for the duration of the attempted allocation. If this variable is set, the STW machinery will refrain from suspending the thread in much the same way as it would when checking the thread’s instruction pointer against the code ranges of the managed allocators.

So the fix to this whole problem is actually very simple: We just set up a critical region in the managed allocator, just like we do in the native SGen functions. That is, we wrap all the code we emit in the managed allocator like so:

static MonoMethod *
create_allocator (int atype, ManagedAllocatorVariant variant)
    // ... snip ...

    MonoMethodBuilder *mb = mono_mb_new (mono_defaults.object_class, name, MONO_WRAPPER_ALLOC);
    int thread_var;

    // ... snip ...

    EMIT_TLS_ACCESS_VAR (mb, thread_var);

    mono_mb_emit_byte (mb, CEE_LDC_I4_1);
    mono_mb_emit_byte (mb, MONO_CUSTOM_PREFIX);
    mono_mb_emit_byte (mb, CEE_MONO_ATOMIC_STORE_I4);
    mono_mb_emit_i4 (mb, MONO_MEMORY_BARRIER_NONE);

    // ... snip: allocation logic ...

    mono_mb_emit_byte (mb, CEE_LDC_I4_0);
    mono_mb_emit_byte (mb, MONO_CUSTOM_PREFIX);
    mono_mb_emit_byte (mb, CEE_MONO_ATOMIC_STORE_I4);
    mono_mb_emit_i4 (mb, MONO_MEMORY_BARRIER_REL);

    // ... snip ...

    MonoMethod *m = mono_mb_create (mb, csig, 8, info);
    mono_mb_free (mb);

    return m;

With that done, SGen will correctly detect that a managed allocator is executing no matter how many signal handlers may be nested on the thread. Checking the in_critical_region variable also happens to be quite a bit cheaper than looking up JIT info for the managed allocators.

Performance Implications

I ran this small program before and after the changes:

using System;

class Program {
    public static object o;

    static void Main ()

        for (var i = 0; i < 100000000; i++)
            o = new object ();


real    0m0.625s
user    0m0.652s
sys     0m0.032s


real    0m0.883s
user    0m0.948s
sys     0m0.012s

So we’re observing about a 40% slowdown from this change on a microbenchmark that does nothing but allocate. The slowdown comes from the managed allocators now having to do two atomic stores, one of which also carries with it a memory barrier with release semantics.

So on one hand, the slowdown is not great. But on the other hand, there is no point in being fast if Mono is crashy as a result. To put things in perspective, this program is still way slower without managed allocators (MONO_GC_DEBUG=no-managed-allocator):

real    0m7.678s
user    0m8.529s
sys     0m0.024s

Managed allocators are still around 770% faster. The 40% slowdown doesn’t seem like much when you consider these numbers, especially when it’s for the purpose of fixing a crash.

More detailed benchmark results from the Xamarin benchmarking infrastructure can be found here.


By setting up a critical region in SGen’s managed allocator methods, we’ve fixed a number of random crashes that would occur when using sample profiling together with the SGen GC. A roughly 40% slowdown was observed on one microbenchmark, however, managed allocators are still around 770% faster than SGen’s native allocation functions, so it’s a small price to pay for a more reliable Mono.

In the next post, we’ll take a look at an issue that plagued profiler users on OS X: A crash when sending sampling signals to threads that hadn’t yet finished basic initialization in libc, leading to broken TLS access. This issue forced us to rewrite the sampling infrastructure in the runtime.