Fix markdownlint warnings

_posts/2017-05-17-concurrent-gc-news.md

@@ -5,34 +5,31 @@ author: Rodrigo Kumpera, Miguel de Icaza
 tags: [runtime]
 ---
 
-
 # Concurrent GC
 
 In Mono 5.0 we are shipping a new operation mode for our Garbage Collector: Concurrent Garbage Collection.
 
 Traditionally, when Mono’s memory manager determined that it should perform a garbage collection, the collector had to pause all Mono running threads, perform the garbage collection, and once it was done, it resumed the execution of those threads.
 
-With concurrent garbage collection, we are able to perform collections on the old generation (what we call major collections) mostly concurrently with your application - it happens at the same time as your program is running.    When the major collection is completed, the collector only needs to pause the Mono threads for a very brief period of time at the end.  
+With concurrent garbage collection, we are able to perform collections on the old generation (what we call major collections) mostly concurrently with your application - it happens at the same time as your program is running.    When the major collection is completed, the collector only needs to pause the Mono threads for a very brief period of time at the end.
 
 This was an important feature for both our users of desktop workloads (like running Xamarin Studio, or Visual Studio for Mac) as well as game and mobile developers that did not want their application to exhibit large pauses when they had very large memory heaps to be collected.
 
 The concurrent garbage collector is now enabled on Mono deployments by default, and we are making it available as an experimental option to all Xamarin platforms (Xamarin.Android, Xamarin.iOS, Xamarin.Mac, Xamarin.tvOS, Xamarin.watchOS).
 
 We are rolling it out as the default on desktop first since it has more friendly hardware and it has received the most tuning.  We are interested in hearing your experiences with the collector with your mobile applications to help us further tune the heuristics in the collector.
 
-To get a sense of how this affect real world applications, let us examine Xamarin Studio.  
+To get a sense of how this affect real world applications, let us examine Xamarin Studio.
 
 Long GC latency can cause typing delays that are noticeable and lead to a bad typing experience. Pauses over 100-150ms are noticeable by most of us [1].
 
 To give you a taste of how the concurrent collector improves things, I used it with Xamarin Studio to open itself, and build itself.  This is one of the biggest solutions that I had around. As I open and build it, Xamarin Studio will be frantically allocating objects which, in turn, trigger the garbage collector - those GC pauses can be felt as hiccups when typing.
 
 The experiment is to run this with and without the concurrent mode enabled. We measured the pause time of each GC run and grouped them in buckets by duration. For example, the 20ms bucket has all collections that paused between 10ms and 20ms. One thing to keep in mind is that the Y axis is in logarithmic scale, as the number of short pauses is significantly larger.
-
 
 ![GC Pause Times](/images/concurrent-gc-pause-times.png)
 
-
-The result is that the long pauses, 200ms, 500ms and higher are now completely gone and even the worst case for concurrent GC shows that there are fewer 150ms pauses. 
+The result is that the long pauses, 200ms, 500ms and higher are now completely gone and even the worst case for concurrent GC shows that there are fewer 150ms pauses.
 
 Even if those numbers are a significant quality of life improvement, there's plenty of work left for us to get to no visible delays due to the garbage collector. We have already a solid pipeline of improvements coming on our next releases.
 
@@ -42,10 +39,8 @@ Our focus for the next year is to leverage this work to satisfy the needs of bot
 
 In the immediate roadmap, you can expect:
 
-
 - Mono 5.2 will introduce an optional parallel major collection mode to speed up the finishing pause for large heaps. This will help with some of the outliers we saw above.
 
-
 - Mono 5.4 will introduce and optional parallel minor collection mode that will help workloads with high activity on old objects. Roslyn falls into this category.
 
 ## Using the Concurrent GC
@@ -56,11 +51,11 @@ On Xamarin.Android and Xamarin.iOS to enable it, go to project settings, under b
 
 ## Tuning the Nursery Size
 
-The graph above shows the defaults for Mono.   
+The graph above shows the defaults for Mono.
 
 In Mono, the Nursery is the name that we give to the youngest heap generation.   When we talk about performing a minor collection, we talk about performing a collection that is limited to the nursery.
 
-For games and other interactive applications that might create lots of small objects during their rendering cycle that are not long-lived, you might be able to take advantage of making the nursery size larger.   
+For games and other interactive applications that might create lots of small objects during their rendering cycle that are not long-lived, you might be able to take advantage of making the nursery size larger.
 
 This reduces the chances that you will hit the limit that would trigger a major collection, and you can manually trigger a complete GC at a convenient time with `GC.Collect()` .
 

docs/about-mono/legal.md

@@ -12,7 +12,7 @@ This does not include Mono source code.
 
 Sample code shown on the website is licensed under the [MIT license](https://opensource.org/licenses/MIT).
 
---------------------------------------
+---
 
 The Debian Open Use Logo(s) are Copyright (c) 1999 Software in the Public Interest, Inc., and are released under the terms of the GNU Lesser General Public License, version 3 or any later version, or, at your option, of the Creative Commons Attribution-ShareAlike 3.0 Unported License. [https://www.debian.org/](https://www.debian.org/).
 

docs/about-mono/releases/5.4.0.md

@@ -14,7 +14,6 @@ Release History
 Highlights
 ==========
 
-
 In Depth
 ========
 
@@ -56,7 +55,6 @@ This shown up as a performance issue during Visual Studio for Mac first project
 
 This avoid boxing and unboxing an intermediary object. This results in a 30x speedup on a microbenchmark.
 
-
 ### Revamped unaligned memory access support
 
 As part of our work to support dotnet platform advances, proper unaligned access was missing from the mono runtime.

docs/advanced/runtime/docs/mono-error.md

@@ -92,7 +92,6 @@ Important points from the above:
 - Given we're still transitioning, not all code can handle in the same ways
 - Since all calls that take a MonoError init it, only check it after the first call;
 
-
 Handling the transition
 =======================
 

docs/debug+profile/clang/threadsanitizer.md

@@ -11,6 +11,7 @@ The [ThreadSanitizer](https://clang.llvm.org/docs/ThreadSanitizer.html) is integ
 $ cd /home/root/of/mono
 $ ./autogen.sh --prefix=/usr/local CC=clang CFLAGS=-fsanitize=thread LDFLAGS=-fsanitize=thread CXX=clang++
 $ make
+...
 ```
 
 Please mind that `CXX` has to be set to `clang++` to avoid unwanted side effects and compiling errors.
@@ -29,6 +30,7 @@ $ touch /home/some/path/blacklist
 $ cd /home/root/of/mono
 $ ./autogen.sh --prefix=/usr/local CC=clang CFLAGS="-fsanitize=thread -fsanitize-blacklist=/home/some/path/blacklist" LDFLAGS=-fsanitize=thread CXX=clang++
 $ make
+...
 ```
 
 Currently (July 2017) it seems like a good idea to leave all blacklist files outside of the repository, as sometimes `autogen.sh` treats blacklist files like source files and lists them as dependencies. As an additional, positive side effect, the blacklist files will not interfere with git.
@@ -99,6 +101,7 @@ Clang's ThreadSanitizer supports a lot of [compiler options](https://github.com/
 $ cd /home/root/of/mono
 $ ./autogen.sh --prefix=/usr/local CC=clang CFLAGS="-fsanitize=thread -fsanitize-blacklist=/home/some/path/blacklist -mllvm -tsan-instrument-atomics=false" LDFLAGS=-fsanitize=thread CXX=clang++
 $ make
+...
 ```
 
 ### Runtime Options
@@ -108,6 +111,7 @@ Clang's ThreadSanitizer also supports various [runtime options](https://github.c
 ``` bash
 $ cd /home/root/of/mono
 $ TSAN_OPTIONS="foo=bar foo2=bar2 foo3=bar3" make
+...
 ```
 
 Please be aware that the runtime options have to be set everytime a ThreadSanitizer-annotated program is used. `TSAN_OPTIONS` is only applied to the `make` process in the example code above. When using `mono` later, `TSAN_OPTIONS` has to be provided again.

docs/debug+profile/debug/index.md

@@ -187,13 +187,12 @@ One of the obviously incorrect way to use locks is to have multiple locks and ac
 ``` csharp
 using System;
 using System.Threading;
- 
+
 class TestDeadlock {
- 
+
     static object lockA = new object ();
     static object lockB = new object ();
- 
- 
+
     static void normal_order () {
         lock (lockA) {
              Console.WriteLine ("took lock A");
@@ -408,7 +407,7 @@ The full options available are:
 ``` bash
 Tracing options:
    --trace[=EXPR]        Trace every call, optional EXPR controls the scope
- 
+
 EXPR is composed of:
     all                  All assemblies
     none                 No assemblies