Fix markdownlint warnings

Author: akoeplinger

_posts/2016-08-16-lock-free-gc-handles.md

@@ -28,14 +28,14 @@ In addition to programmers’ regular use of handles, Mono uses them in its impl
 
 A `GCHandle` object consists of a type and an index, packed together into a 32-bit unsigned integer. To get the value of a handle, say with `WeakReference.Target`, we first look up the array of handle data corresponding to its type, then look up the value at the given index; in pseudocode:
 
-```
+```text
 (type, index) = unpack(handle)
 value = handles[type][index]
 ```
 
 The original implementation of GC handles was based on a bitmap allocator. For each handle type, it stored a bitmap indicating the available slots for allocating new handles, and an array of pointers to their target objects:
 
-```
+```text
 bitmap   = 11010…
 pointers = [0xPPPPPPPP, 0xPPPPPPPP, NULL, 0xPPPPPPPP, NULL, …]
 ```
@@ -44,7 +44,7 @@ There’s an interesting constraint, though: when we unload an `AppDomain`, we w
 
 But if the weak reference has expired, we can’t tell what domain it came from, because we no longer have an object to look at! So for weak references, we kept a parallel array of domain pointers:
 
-```
+```text
 domains  = [0xDDDDDDDD, 0xDDDDDDDD, NULL, 0xDDDDDDDD, NULL, …]
 ```
 
@@ -65,21 +65,21 @@ After removing the redundant hash table, the first step toward a new lock-free i
 
 We ended up with a single array of *slots* in the following bit format:
 
-```
+```text
 PPPPPPPP…0VX
 ```
 
 Where `PPPP…` are pointer bits, `V` is the “valid” flag, and `X` is the “occupied” flag, packed together with bitwise OR:
 
-```
+```text
 slot = pointer | valid_bit | occupied_bit
 ```
 
 If the “occupied” flag is clear, the slot is free to be claimed by `GCHandle.Alloc`. To allocate a handle, we use a CAS (“compare and swap”, also known as [`Interlocked.CompareExchange`][Interlocked.CompareExchange]) to replace a null slot with a tagged pointer, where the “occupied” and “valid” flags are set:
 
 [Interlocked.CompareExchange]: https://msdn.microsoft.com/en-us/library/system.threading.interlocked.compareexchange(v=vs.110).aspx
 
-```
+```text
 cas(slot, tag(pointer), NULL)
 
 00000000…000
@@ -93,7 +93,7 @@ As for `AppDomain` unloading, we can observe that we only need to store a domain
 
 Therefore, when a weak reference expires, all we have to do is clear the “valid” flag and replace the object pointer with a domain pointer:
 
-```
+```text
 PPPPPPPP…011
      ↓
 DDDDDDDD…001
@@ -116,7 +116,7 @@ Now that we have our representation of slots, how do we grow the handle array wh
 
 To solve this, instead of a single handle array, we use a handle *table* consisting of an array of *buckets*, each twice the size of the last:
 
-```
+```text
 [0] → xxxxxxxx
 [1] → xxxxxxxxxxxxxxxx
 [2] → xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
@@ -139,15 +139,15 @@ If the CAS fails, then another thread has already allocated a new bucket, so we
 
 Before this change was implemented, these were the average timings over 5 runs:
 
-```
+```bash
 real    0m2.441s
 user    0m1.591s
 sys     0m0.959s
 ```
 
 After the change:
 
-```
+```bash
 real    0m0.358s
 user    0m0.406s
 sys     0m0.063s
@@ -157,15 +157,15 @@ Cool! We got about an 80% improvement.
 
 Let’s look at `monitor-stress`, which stress-tests `Monitor` operations using the C♯ `lock` statement. Before the change, average of 5 runs:
 
-```
+```bash
 real    0m2.714s
 user    0m6.963s
 sys     0m0.244s
 ```
 
 Now, with the change:
 
-```
+```bash
 real    0m2.681s
 user    0m6.783s
 sys     0m0.242s

_posts/2016-09-07-profiler-managed-allocators.md

@@ -43,19 +43,19 @@ 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.
-	 */
+    /*
+     * 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);
+    MonoJitInfo *ji = mono_jit_info_table_find_internal (domain, ip, FALSE, FALSE);
 
-	if (!ji)
-		return FALSE;
+    if (!ji)
+        return FALSE;
 
-	MonoMethod *m = mono_jit_info_get_method (ji);
+    MonoMethod *m = mono_jit_info_get_method (ji);
 
-	return sgen_is_managed_allocator (m);
+    return sgen_is_managed_allocator (m);
 }
 ```
 
@@ -66,7 +66,7 @@ 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
 (gdb) bt
 #0  0x0000000000400564 in sigusr2_signal_handler ()
 #1  <signal handler called>
@@ -78,7 +78,7 @@ to your program, you'll see a stack trace looking something like this:
 Unsurprisingly, if we print the instruction pointer, we'll find that it's
 pointing into the most recently called signal handler:
 
-```
+```gdb
 (gdb) p $pc
 $1 = (void (*)()) 0x400564 <sigusr2_signal_handler+15>
 ```
@@ -90,7 +90,7 @@ 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:
 
-```
+```gdb
 #0 suspend_signal_handler ()
 #1 <signal handler called>
 #2 profiler_signal_handler ()
@@ -103,7 +103,7 @@ like this:
 
 Under normal (non-profiling) circumstances, it would look like this:
 
-```
+```gdb
 #0 suspend_signal_handler ()
 #1 <signal handler called>
 #2 AllocSmall ()
@@ -180,29 +180,29 @@ at how SGen allocates a `System.String` in the native allocation functions:
 MonoString *
 mono_gc_alloc_string (MonoVTable *vtable, size_t size, gint32 len)
 {
-	TLAB_ACCESS_INIT;
+    TLAB_ACCESS_INIT;
 
-	ENTER_CRITICAL_REGION;
+    ENTER_CRITICAL_REGION;
 
-	MonoString *str = sgen_try_alloc_obj_nolock (vtable, size);
+    MonoString *str = sgen_try_alloc_obj_nolock (vtable, size);
 
-	if (str)
-		str->length = len;
+    if (str)
+        str->length = len;
 
-	EXIT_CRITICAL_REGION;
+    EXIT_CRITICAL_REGION;
 
-	if (!str) {
-		LOCK_GC;
+    if (!str) {
+        LOCK_GC;
 
-		str = sgen_alloc_obj_nolock (vtable, size);
+        str = sgen_alloc_obj_nolock (vtable, size);
 
-		if (str)
-			str->length = len;
+        if (str)
+            str->length = len;
 
-		UNLOCK_GC;
-	}
+        UNLOCK_GC;
+    }
 
-	return str;
+    return str;
 }
 ```
 
@@ -233,35 +233,35 @@ so:
 static MonoMethod *
 create_allocator (int atype, ManagedAllocatorVariant variant)
 {
-	// ... snip ...
+    // ... snip ...
 
-	MonoMethodBuilder *mb = mono_mb_new (mono_defaults.object_class, name, MONO_WRAPPER_ALLOC);
-	int thread_var;
+    MonoMethodBuilder *mb = mono_mb_new (mono_defaults.object_class, name, MONO_WRAPPER_ALLOC);
+    int thread_var;
 
-	// ... snip ...
+    // ... snip ...
 
-	EMIT_TLS_ACCESS_VAR (mb, thread_var);
+    EMIT_TLS_ACCESS_VAR (mb, thread_var);
 
-	EMIT_TLS_ACCESS_IN_CRITICAL_REGION_ADDR (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);
+    EMIT_TLS_ACCESS_IN_CRITICAL_REGION_ADDR (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 ...
+    // ... snip: allocation logic ...
 
-	EMIT_TLS_ACCESS_IN_CRITICAL_REGION_ADDR (mb, thread_var);
-	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);
+    EMIT_TLS_ACCESS_IN_CRITICAL_REGION_ADDR (mb, thread_var);
+    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 ...
+    // ... snip ...
 
-	MonoMethod *m = mono_mb_create (mb, csig, 8, info);
-	mono_mb_free (mb);
+    MonoMethod *m = mono_mb_create (mb, csig, 8, info);
+    mono_mb_free (mb);
 
-	return m;
+    return m;
 }
 ```
 
@@ -278,27 +278,27 @@ I ran this small program before and after the changes:
 using System;
 
 class Program {
-	public static object o;
+    public static object o;
 
-	static void Main ()
-	{
-		for (var i = 0; i < 100000000; i++)
-			o = new object ();
-	}
+    static void Main ()
+
+        for (var i = 0; i < 100000000; i++)
+            o = new object ();
+    }
 }
 ```
 
 Before:
 
-```
+```bash
 real    0m0.625s
 user    0m0.652s
 sys     0m0.032s
 ```
 
 After:
 
-```
+```bash
 real    0m0.883s
 user    0m0.948s
 sys     0m0.012s
@@ -314,7 +314,7 @@ 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`):
 
-```
+```bash
 real    0m7.678s
 user    0m8.529s
 sys     0m0.024s

_posts/2016-09-12-arm64-icache.md

@@ -4,6 +4,7 @@ title: "A tale of an impossible bug: big.LITTLE and caching"
 author: Rodrigo Kumpera and Bernhard Urban
 tags: [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](https://en.wikipedia.org/wiki/ARM_big.LITTLE)
 is the first mass produced
@@ -38,7 +39,7 @@ This was our only clue, and there are no coincidences when it comes to this sort
 and the `SIGILL` would [always happen to be somewhere between](https://gist.github.com/lewurm/97dff0a56929b56a0fc5ab49af06fd06) `0x40-0x7f` or `0xc0-0xff`.
 We aligned the memory dump to help verify whether the code allocator was doing something funky:
 
-```
+```bash
 $ grep SIGILL *.log
 custom_01.log:E/mono           (13964): SIGILL at ip=0x0000007f4f15e8d0
 custom_02.log:E/mono           (13088): SIGILL at ip=0x0000007f8ff76cc0
@@ -58,12 +59,12 @@ Here is a pseudo version of how `libgcc` [does cache flushing on arm64](https://
 ```c
 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 ();
+    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);
+    for (int i = 0; i < size; i += cache_line_size)
+        flush_cache_line (address + i);
 }
 ```
 

_posts/2016-11-29-mono-code-sharing.md

@@ -10,7 +10,7 @@ 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](https://github.com/microsoft/referencesource) code into Mono. 
+Source](https://github.com/microsoft/referencesource) code into Mono.
 
 We have been using the Reference Source code instead of the
 [CoreFX](https://github.com/dotnet/corefx), as Mono implements a