Author: Konrad Kokosa

Getting rid of array bound checks using ref-returns and .NET 5

September 29, 2020 by Konrad Kokosa·3 Comments

Imagine we have a simple class, a wrapper around some array of structs (better data locality etc.):

public class ArrayChunkOfStructs<T> where T : struct
{
  private readonly T[] _array;

  public ArrayChunkOfStructs(int size)
  {
    _array = new T[size];
  }
  ...
}

public class ArrayChunkOfStructs<T> where T : struct

{

private readonly T[] _array;

public ArrayChunkOfStructs(int size)

{

_array = new T[size];

}

...

}

Now, I would like to have an efficient access to every element. Obviously, a trivial indexer would be inefficient here, as it would return a copy of the given array element (a struct):

public T this[int index] => _array[index];

1	public T this[int index] => _array[index];

Luckily, since C# 7.0 we can “ref return” to efficiently return a reference to a given array element which is super nice (refer to my article about ref for more info):

public ref T this[int index] => ref _array[index];

1	public ref T this[int index] => ref _array[index];

Here, 99.9999% of devs will stop and will be satisfied with the semantics and performance results. But… if we know we will call it tremendously often, can we do better?!

First of all, let’s see what is being JITted by the .NET Core x64 runtime (5.0rc) when accessing 9th element (index is 8):

; AbusingCSharp.Benchmarks.ArrayChunkBenchmarks.TestIndexerRef()
sub rsp,28
mov rax,[rcx+8]
mov rax,[rax+8]
cmp dword ptr [rax+8],8
jbe short M00_L00
add rax,30
add rsp,28
ret
M00_L00:
call CORINFO_HELP_RNGCHKFAIL
int 3
; Total bytes of code 33

; AbusingCSharp.Benchmarks.ArrayChunkBenchmarks.TestIndexerRef()

sub rsp,28

mov rax,[rcx+8]

mov rax,[rax+8]

cmp dword ptr [rax+8],8

jbe short M00_L00

add rax,30

add rsp,28

ret

M00_L00:

call CORINFO_HELP_RNGCHKFAIL

int 3

; Total bytes of code 33

To those who know assembler a little, it may be clear what is going on here. But let’s make a short summary:

we see a little of “stack frame” creation here (sub/add rsp) – could we get rid of it in such a simple method?
we see bound check in line 4 (cmp the index to 8) to check if we are accessing an array with a correct index – could we get rid of it because we trust our code? 😇

Disclaimer: Getting rid of bound checks is very risky and the resulting dangers probably will overcome the performance benefits. Thus, use it only after heavy consideration, if you are sure why you need it and you can ensure caller’s code will be correct (providing valid indices).

To continue, we will be walking on thin ice of unsafe code now.

The first idea is to use Unsafe.Add to provide kind of “pointer arithmetic” – add an index-element to the first element:

public ref T ItemRef(int index)
  => ref Unsafe.Add(ref _array[0], index);

1 2	public ref T ItemRef(int index) => ref Unsafe.Add(ref _array[0], index);

The “problem” here is, it produces almost identical results because _array[0] is still a bound-checked array access (and we don’t get rid of stack frame too):

; AbusingCSharp.Benchmarks.ArrayChunkBenchmarks.TestItemRef()
sub rsp,28
mov rax,[rcx+8]
mov rax,[rax+8]
cmp dword ptr [rax+8],0
jbe short M00_L00
add rax,10
add rax,20
add rsp,28
ret
M00_L00:
call CORINFO_HELP_RNGCHKFAIL
int 3
; Total bytes of code 37

; AbusingCSharp.Benchmarks.ArrayChunkBenchmarks.TestItemRef()

sub rsp,28

mov rax,[rcx+8]

mov rax,[rax+8]

cmp dword ptr [rax+8],0

jbe short M00_L00

add rax,10

add rax,20

add rsp,28

ret

M00_L00:

call CORINFO_HELP_RNGCHKFAIL

int 3

; Total bytes of code 37

Hence, the non trivial question arises – how to get the address/ref to the first element of an array?

We could think of doing some Span-based magic (to use MemoryMarshal.GetReference):

public ref T ItemRef2(int index)
{
  var span = new Span<T>(_array);
  return ref Unsafe.Add(ref MemoryMarshal.GetReference(span), index);
}

public ref T ItemRef2(int index)

{

var span = new Span<T>(_array);

return ref Unsafe.Add(ref MemoryMarshal.GetReference(span), index);

}

But you can probably feel it – it produces even slower and bigger code (Span creation handling etc.) while still bound check will be there (Span is “safe”).

So, we need somehow to find a better way of getting an address of the first array’s element. The thing is, the internal structure of the array type is an implementation detail (although well-known). How can we overcome that?

The idea is… to rely on that implementation detail. This approach is being used by DangerousGetReferenceAt method from Microsoft.Toolkit.HighPerformance package maintained by Sergio Pedri. DangerousGetReferenceAt source code explains it well:

public static ref T DangerousGetReferenceAt<T>(this T[] array, int i)
{
#if NETCORE_RUNTIME
  var arrayData = Unsafe.As<RawArrayData>(array);
  ref T r0 = ref Unsafe.As<byte, T>(ref arrayData.Data);
  ref T ri = ref Unsafe.Add(ref r0, i);

  return ref ri;
#else
  ...
#endif
}

// Description taken from CoreCLR: see https://source.dot.net/#System.Private.CoreLib/src/System/Runtime/CompilerServices/RuntimeHelpers.CoreCLR.cs,285.
// CLR arrays are laid out in memory as follows (multidimensional array bounds are optional):
// [ sync block || pMethodTable || num components || MD array bounds || array data .. ]
// ^ ^ ^ returned reference
// | \-- ref Unsafe.As<RawArrayData>(array).Data
// \-- array
// The base size of an array includes all the fields before the array data,
// including the sync block and method table. The reference to RawData.Data
// points at the number of components, skipping over these two pointer-sized fields.
[StructLayout(LayoutKind.Sequential)]
private sealed class RawArrayData
{
#pragma warning disable CS0649 // Unassigned fields
#pragma warning disable SA1401 // Fields should be private
  public IntPtr Length;
  public byte Data;
#pragma warning restore CS0649
#pragma warning restore SA1401
}

public static ref T DangerousGetReferenceAt<T>(this T[] array, int i)

{

#if NETCORE_RUNTIME

var arrayData = Unsafe.As<RawArrayData>(array);

ref T r0 = ref Unsafe.As<byte, T>(ref arrayData.Data);

ref T ri = ref Unsafe.Add(ref r0, i);

return ref ri;

#else

...

#endif

}

// Description taken from CoreCLR: see https://source.dot.net/#System.Private.CoreLib/src/System/Runtime/CompilerServices/RuntimeHelpers.CoreCLR.cs,285.

// CLR arrays are laid out in memory as follows (multidimensional array bounds are optional):

// [ sync block || pMethodTable || num components || MD array bounds || array data .. ]

// ^ ^ ^ returned reference

// | \-- ref Unsafe.As<RawArrayData>(array).Data

// \-- array

// The base size of an array includes all the fields before the array data,

// including the sync block and method table. The reference to RawData.Data

// points at the number of components, skipping over these two pointer-sized fields.

[StructLayout(LayoutKind.Sequential)]

private sealed class RawArrayData

{

#pragma warning disable CS0649 // Unassigned fields

#pragma warning disable SA1401 // Fields should be private

public IntPtr Length;

public byte Data;

#pragma warning restore CS0649

#pragma warning restore SA1401

}

So, we are casting (reinterpreting) an array reference as a reference to some artificial RawArrayData class, which has a layout corresponding to an array layout. Thus, getting “data” reference is now just trivial. No bound checks at all!

The good news is this method has been ported to .NET 5! So, in .NET 5.0rc we can already use MemoryMarshal.GetArrayDataReference which does exactly the same thing:

public static ref T GetArrayDataReference<T>(T[] array)
  => ref Unsafe.As<byte, T>(ref Unsafe.As<RawArrayData>(array).Data);

1 2	public static ref T GetArrayDataReference<T>(T[] array) => ref Unsafe.As<byte, T>(ref Unsafe.As<RawArrayData>(array).Data);

Thus, without any external dependencies our code in .NET 5 may be rewritten to:

public ref T ItemRef3(int index)
{
  ref var data = ref MemoryMarshal.GetArrayDataReference(_array);
  return ref Unsafe.Add(ref data, index);
}

public ref T ItemRef3(int index)

{

ref var data = ref MemoryMarshal.GetArrayDataReference(_array);

return ref Unsafe.Add(ref data, index);

}

And the resulting code is indeed much more lightweight:

; AbusingCSharp.Benchmarks.ArrayChunkBenchmarks.TestItemRef3()
mov rax,[rcx+8]
mov rax,[rax+8]
cmp [rax],eax
add rax,10
add rax,20
ret
; Total bytes of code 19

; AbusingCSharp.Benchmarks.ArrayChunkBenchmarks.TestItemRef3()

mov rax,[rcx+8]

mov rax,[rax+8]

cmp [rax],eax

add rax,10

add rax,20

ret

; Total bytes of code 19

No bound-checks, and as an additional reward from the method simplicity – no stack frame.

Benchmarks are indeed showing a noticeable (well, in ns order of magnitude) difference:

| Method         | Mean      | Error      | StdDev   | Ratio | 
|--------------- |----------:|----------:|----------:|------:|
| TestIndexerRef | 0.4254 ns | 0.0433 ns | 0.0464 ns | 1.00  |
| TestItemRef    | 0.3497 ns | 0.0261 ns | 0.0244 ns | 0.82  |
| TestItemRef2   | 1.4914 ns | 0.0204 ns | 0.0171 ns | 3.50  |
| TestItemRef3   | 0.0942 ns | 0.0194 ns | 0.0172 ns | 0.22  |

|--------------- |----------:|----------:|----------:|------:|

| TestIndexerRef | 0.4254 ns | 0.0433 ns | 0.0464 ns | 1.00 |

| TestItemRef | 0.3497 ns | 0.0261 ns | 0.0244 ns | 0.82 |

| TestItemRef2 | 1.4914 ns | 0.0204 ns | 0.0171 ns | 3.50 |

| TestItemRef3 | 0.0942 ns | 0.0194 ns | 0.0172 ns | 0.22 |

Which simply means, we are now about 5x faster than with the initial solution!

Disclaimer #2: Approach taken here with the usage of GetArrayDataReferece is super dangerous. As Levi Broderick, one of .NET framework developers, said: “Also, read the method documentation. It does more than remove bounds checks; it also removes array variance checks. So it might not be valid to write to the ref, even if the index is within bounds. Misuse of the method will bite you in the ass, guaranteed.” Moreover, documentation clearly states that “a reference may be used for pinning but must never be dereferenced” 😇

GitHub Actions and sample NuGet-based library

September 24, 2020 by Konrad Kokosa·1 Comment

We all use libraries from NuGet tremendously often. But how many times you’ve created your own, even the simplest library that is being published there? I expect, not so often… So do I. Thus, I decided to make the super simple example of doing that, while utilizing the new and shiny GitHub Actions for all automations.

This serves many purposes, as often when I do something:

Minimum Viable Product (or example) of creating your own library that is automatically tested/versioned and published as a NuGet package – it requires to combine various building blocks and it turns out to be not-so-trivial. My goal would be to provide it as a kind of template for creating a new NuGet-based libraries.
playground for fresh open source contributors that are willing to do some contributions that will be then propagated to a regular NuGet package – without a risk and fear of destroying something
funny, joke-like package that, still, may be extended/improved
and obviously, a great place to learn all this stuff (including me)

So this is how Strings.Abbreviations has been coined. A very simple C#-based library that makes the simplest thing I could imagine – provide sets of methods that resolve popular abbreviations like BRB or IMHO. For example Strings.BRB() with return “Be right back” string. To add some “logic”, there is an additional option to use “title casing”. So, Strings.BRB(titleCase: true) will return “Be Right Back”.

Obviously, this is trivial but it is by design! Thanks to that there is a very low entrance level for any contributor. Additionally, automation workflow is not hidden inside the complex logic and dependencies.

Initial design

So, this repository is based on a regular solution containing .NET Core library and test project. After the recent PR, there is also a trivial F#-based library (because we can!). As I said, the core part here is that Strings.Abbreviations is build, tested and published as a NuGet package with the use of Github Actions. All workflows we define are living inside the repository under .github/workflows folder. Currently there are two working workflows defined.

Building and testing

Every push and PR to master will trigger building and unit testing the whole solution. What’s super nice – thanks to that the result of the tests are available as an additional PR check. And we have a “badge” available on the top of this file (we will return to that).

Setting this was trivial, as we can use the default .NET Core workflow suggested when using Actions for the very first time. Underneath this workflow uses dotnet restore/build/test commands.

Building and publishing a NuGet package

Every push to master that bumps up Version in the Strings.Abbreviations.csproj file will trigger building and publishing a new NuGet package. Additionally, a new git tag will be pushed with the given version. It uses Publish NuGet custom Github Action which was also really easy to set up thanks to the documentation. All package data are taken from csproj file (no need for a separate .nuspec file). The only additional thing required here is to add NUGET_API_KEY secret key from the repository Settings tab.

Badges

To make our repository more professional and fancy, it is nice to add some “badges”. Readme.md file contains some. One is provided by the build-and-test workflow, and others (like current NuGet version or number of downloads) are provided by super-popular https://shields.io/ site:

[![NuGet](https://img.shields.io/nuget/v/Strings.Abbreviations)](https://www.nuget.org/packages/Strings.Abbreviations/)
[![Downloads](https://img.shields.io/nuget/dt/Strings.Abbreviations)](https://www.nuget.org/packages/Strings.Abbreviations/)
[![Stars](https://img.shields.io/github/stars/kkokosa/Strings.Abbreviations)](https://github.com/kkokosa/Strings.Abbreviations/stargazers)
[![License](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE.md)

[![NuGet](https://img.shields.io/nuget/v/Strings.Abbreviations)](https://www.nuget.org/packages/Strings.Abbreviations/)

[![Downloads](https://img.shields.io/nuget/dt/Strings.Abbreviations)](https://www.nuget.org/packages/Strings.Abbreviations/)

[![Stars](https://img.shields.io/github/stars/kkokosa/Strings.Abbreviations)](https://github.com/kkokosa/Strings.Abbreviations/stargazers)

[![License](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE.md)

What’s next?

It is not a full MVP still. There is a field of many improvements to make it a true template for potential library authors, including:

the next big thing to add is producing GitHub releases every time a new version is being created. I wanted to depend on version tags being already pushed by the publish-nuget workflow. Unfortunately I have an issue with that.
GitHub Actions for creating prerelease versions
some simple documentation auto-generation example, like the list of currently supported abbreviations
more automated tests, like code coverage or even benchmarks
the core “logic” improvement, like auto-generating title case versions, more abbreviations, more languages etc.
…? Any other good, not-to-complex automation ideas

So, in the end, please feel invited to look around and help me building it with your contributions. Any contributions to the “logic” itself is also welcomed!

await false & await true

June 10, 2020 by Konrad Kokosa·0 Comments

Awaitables are the types on which await can be called. It happens due to “duck typing” – the only thing which makes type “awaitable” is an existence of the GetAwaiter() method that returns type implementing INotifyCompletion interface. That’s it.

Obviously, the most popular awaitables are Task and Task<T> so we can await them – this ends up in a possibility to call:

await DoSomethingAsync();

1	await DoSomethingAsync();

if DoSomethingAsync method returns Task or Task<T>. Another popular awaitables are ValueTask & ValueTask<T> and ConfiguredTaskAwaiter & ConfiguredValueTaskAwaiter (when you use ConfigureAwait).

But nothing stops us to write our own awaitables. Moreover, as I said duck typing is involved here so the type itself does not have to define proper GetAwaiter method. We can use extension method and it will satisfy duck typing.

Thus, we can make ANY type awaitable. So, we can make bool awaitable:

internal static class BoolExtensions
{
   public static BoolAwaiter GetAwaiter(this bool value) => new BoolAwaiter(value);
}

internal static class BoolExtensions

{

public static BoolAwaiter GetAwaiter(this bool value) => new BoolAwaiter(value);

}

Awaiter uses yet another set of duck-typed methods to satisfy underlying state machine:

internal class BoolAwaiter : INotifyCompletion
{
  private readonly bool _value;
  public BoolAwaiter(bool value) => _value = value;

  public bool IsCompleted => true;
  public void OnCompleted(Action continuation) { } // Never called
  public bool GetResult() => _value;
}

internal class BoolAwaiter : INotifyCompletion

{

private readonly bool _value;

public BoolAwaiter(bool value) => _value = value;

public bool IsCompleted => true;

public void OnCompleted(Action continuation) { } // Never called

public bool GetResult() => _value;

}

Because IsCompleted is always true (checked by the underlying async state machine), GetResult will be called for the result. Here OnCompleted is never called because it is a callback called when the operation “completed” (to execute continuation somehow).

So now we can write:

var result = await false; // result will be false
var result = await true; // result will be true

1 2	var result = await false; // result will be false var result = await true; // result will be true

And because GetResult returns bool… which is now awaitable, we can make recurrent calls:

await await true;
await await await false;

1 2	await await true; await await await false;

And because in the end it is a bool, it has its all normal operators:

await (await await false && await true);

1	await (await await false && await true);

Summary

BoolAwaiter presented here is just for an educational purposes to better understand awaitables. And for fun a little. You can write your own, for example making int awaitable 🙂 Obviously, it has no practical usage and may be even dangerous (imagine a DoAsync method returning int instead of Task<int> by mistake).

If you found it interesting, this is just an example of work for a much bigger project – I really do believe it’s going to be the best in the market on-line course about asynchronous and concurrent programming in .NET.

The danger of async/await and .Result in one picture

June 2, 2020 by Konrad Kokosa·2 Comments

Sync over async in .NET is always bad and there is no better advice than just to avoid it. What does “Sync over async” mean exactly? It happens if you synchronously wait on an asynchronous operation result with the help of .Result, .Wait or similar. Why is it bad? First of all, it blocks (wastes) one thread to wait on a result – which may lead to threads starvation. But even worse, it may deadlock your operation and (sometimes) the whole application.

Probably you’ve heard all that previously. I just wanted to present a picture, “worth a thousand words“, to explain why does it happen.

There is a concept of SynchronizationContext in .NET – an abstraction that knows how/where schedule a work item (like an async/await continuation). When you await something, SynchronizationContext is being captured. And when continuation is going to be run – we use SynchronizationContext to run the continuation “somewhere”. SynchronizationContext implementation may be different in various scenarios (console, UI, web, mobile applications), because there are various needs to “synchronize” work items. The main example is a GUI-based application. When we start an asynchronous operation on the UI thread, we expect its continuations will “return” to the same thread.

But, if we .Result that operation, the main UI thread is blocked waiting on the result, so it is not able to process anything (including mouse/keyboard events). So there is no way continuation (that would set the result) may run, thus we endlessly wait for the result – deadlock.

That’s why ConfigureAwait helps – it allows to say “I don’t care about scheduling continuation to the original (captured) context“. Thanks to that asynchronous operation continuation is scheduled to a different thread (thread pool’s) and sets the result with no problem. This resumes the main UI thread, and there is no deadlock.

That was just two simple drawings. If you’d like to know more, refer to a great ConfigureAwait FAQ by Stephen Toub.

Again, all this is just a work for a much bigger project, which is awesome Async Expert on-line course about asynchronous and concurrent programming in .NET. If you found it interesting, stay tuned by subscribing to the newsletter on the above-mentioned page!

.NET async/await in a single picture

May 26, 2020 by Konrad Kokosa·4 Comments

It is said that picture is worth a thousand words, and I agree. That’s why I like preparing technical drawings to explain various concepts. So, here it is – a short story of how async/await works in .NET.

The main power behind async/await is that while we “await” on an ongoing I/O operation, the calling thread may be released for doing other work. And this provides a great thread re-usability. Thus, better scalability – much smaller number of threads is able to handle the same amount of operations comparing to asynchronous/waiting approach.

The main role here plays so-called overlapped I/O (in case of Windows) which allows to asynchronously delegate the I/O operation to the operating system, and only after completion the provided callback will notify us about the result. The main workforce here is so-called I/O completion port (IOCP).Continue reading

Pinned Object Heap in .NET 5

May 11, 2020 by Konrad Kokosa·7 Comments

In the upcoming .NET 5 a very interesting change is added to the GC – a dedicated Pinned Object Heap, a very new type of the managed heap segment (as we have Small and Large Object Heaps so far). Pinning has its own costs, because it introduces fragmentation (and in general complicates object compaction a lot). We are used to have some good practices about it, like “pin only for…:

a very short time” so, the GC will not bother – to reduce probability that the GC happens while many objects were pinned. That’s a scenario to use fixed keyword, which is in fact only a very lightweight way of flagging particular local variable as a pinned reference. As long as GC does not happen, there is no additional overhead.
a very long time”, so the GC will promote those objects to generation 2 – as gen2 GCs should be not so common, the impact will be minimized also. That’s a scenario to use GCHandle of type Pinned, which is a little bigger overhead because we need to allocate/free handle.

However, even if applied, those rules will produce some fragmentation, depending how much you pin, for how long, what’s the resulting layout of the pinned objects in memory and many other, intermittent conditions.

So, in the end, it would be perfect just to get rid of pinned objects and move them to a different place than SOH/LOH. This separate place would be simply ignored, by the GC design, when considering heap compaction so we will get pinning behaviour out of the box.Continue reading

.NET JIT compiler is not type safe

April 17, 2020 by Konrad Kokosa·9 Comments

Everyone knows that C# is a strongly typed language and incorrect type usage is simply not possible there. So, the following program will just not compile:

class Program
{
   static void Main(string[] args)
   {
      var s = "Test";
      Console.WriteLine(Consume(s));
      var o = new object();
      Console.WriteLine(Consume(o)); // Error: Argument 1: cannot convert from 'object' to 'string'
   }

   static int Consume(string s) => s.Length;
}

class Program

{

static void Main(string[] args)

{

var s = "Test";

Console.WriteLine(Consume(s));

var o = new object();

Console.WriteLine(Consume(o)); // Error: Argument 1: cannot convert from 'object' to 'string'

}

static int Consume(string s) => s.Length;

}

That’s good, it means we can trust Roslyn (C# compiler) not to generate improper type-safety code. But what if we rewrite the same code to the Common Intermediate Language, omitting completely C# and its compiler?

.method public static int32 IncorrectTypeUse() cil managed
{		
   ldstr "Test"
   call int32 CILApp.Program::ConsumeString(string)
   call void [System.Console]System.Console::WriteLine(int32)
	
   newobj instance void [System.Private.CoreLib]System.Object::.ctor()
   call int32 CILApp.Program::ConsumeString(string)
   call void [System.Console]System.Console::WriteLine(int32)
   ret
}

.method public static int32 ConsumeString(string number) cil managed
{		
   ldarg.0
   callvirt instance int32 [System.Private.CoreLib]System.String::get_Length()
   ret
}

.method public static int32 IncorrectTypeUse() cil managed

{

ldstr "Test"

call int32 CILApp.Program::ConsumeString(string)

call void [System.Console]System.Console::WriteLine(int32)

newobj instance void [System.Private.CoreLib]System.Object::.ctor()

call int32 CILApp.Program::ConsumeString(string)

call void [System.Console]System.Console::WriteLine(int32)

ret

}

.method public static int32 ConsumeString(string number) cil managed

{

ldarg.0

callvirt instance int32 [System.Private.CoreLib]System.String::get_Length()

ret

}

First of all, it will be assembled by ILASM tool without any errors because it is a syntactically correct CIL. And ILASM is not a compiler, so it will not do any type checks on its own. So we end up with an assembly file with a smelly CIL inside. If not using ILASM, we could also simply modify CIL with the help of any tool like dnSpy.

Ok, let’s say that is fine. But what will happen when we try to execute such code? Will .NET runtime verify somehow the CIL of those methods? Just-In-Time compiler for sure will notice type mismatch and do something to prevent executing it, right?

What will happen is the program will just execute without any errors and will print 4 (the length of “Test”) followed by… 0 in a new line. The truth is that JIT or any other part of .NET runtime does not examine type safety.

Why the result is 0? Because when the JIT emits native code of a particular method, it uses type layout information of the data/types being used. And it happens that string.Length property is just an inlined method call that access the very first int field of an object (because string length is stored there):

ConsumeString(System.String)
	L0000: mov eax, [rcx+0x8]	; rcx is the first parameter passed
	L0003: ret

ConsumeString(System.String)

L0000: mov eax, [rcx+0x8] ; rcx is the first parameter passed

L0003: ret

As we pass a newly created object instance, which always has one pointer-sized field initialized to zero (this is a requirement of the current GC), the result is 0.

And yes, if we pass a reference to an object with some int field, its value will be returned (again, instead of throwing any type-safety related runtime exception). The following code (when converted to CIL) will execute with no errors and print 44!

class Program
{
   static void Main(string[] args)
   {
      var c = new C();
      Console.WriteLine(Consume(c)); // Prints 44
   }

   static int Consume(string s) => s.Length;
}
class C
{
   public int X = 44;
}

class Program

{

static void Main(string[] args)

{

var c = new C();

Console.WriteLine(Consume(c)); // Prints 44

}

static int Consume(string s) => s.Length;

}

class C

{

public int X = 44;

}

This all may be quite suprising, so what ECMA-335 standard says about it? Point “II.3 Validation and verification” mentions all CIL verification rules and algorithms and states:

“Aside from these rules, this standard leaves as unspecified:

The time at which (if ever) such an algorithm should be performed.

What a conforming implementation should do in the event of a verification failure.”

And:

“Ordinarily, a conforming implementation of the CLI can allow unverifiable code (valid code that does not pass verification) to be executed, although this can be subject to administrative trust controls that are not part of this standard.”

While indeed .NET runtime does some validation, it does not verify the IL. The difference? If we run the following code:

.method public static int32 IncorrectTypeUse() cil managed
{		
   // no argument provided to the ConsumeString
   call int32 CILApp.Program::ConsumeString(string)
   ret
}

.method public static int32 IncorrectTypeUse() cil managed

{

// no argument provided to the ConsumeString

call int32 CILApp.Program::ConsumeString(string)

ret

}

It will end up with System.InvalidProgramException: Common Language Runtime detected an invalid program. being thrown. So, we can summarize it as the fact that invalid CIL code may trigger InvalidProgramException for some cases, but for others will just allow the program to execute (with many unexpected results). And all this may happen only during JIT compilation, at runtime.

So, what can we do to protect ourselves, before deploying and running it on production? We need to verify our IL on our own. There is PEVerify tool for exactly that purpose, shipped with .NET Framework SDK. You can find one in a folder similar to c:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64\.

When running against our example, it will indeed detect an incorrect method with a proper explanation:

> peverify .\CILApp\bin\Debug\CILApp.exe

Microsoft (R) .NET Framework PE Verifier. Version 4.0.30319.0
Copyright (c) Microsoft Corporation. All rights reserved.

[IL]: Error: [CILApp.exe : CILApp.Program::IncorrectTypeUse][offset 0x00000005]
[found ref 'CILApp.C'][expected ref 'System.String'] Unexpected type on the stack.
1 Error(s) Verifying CILApp.exe

> peverify .\CILApp\bin\Debug\CILApp.exe

Microsoft (R) .NET Framework PE Verifier. Version 4.0.30319.0

[IL]: Error: [CILApp.exe : CILApp.Program::IncorrectTypeUse][offset 0x00000005]

[found ref 'CILApp.C'][expected ref 'System.String'] Unexpected type on the stack.

1 Error(s) Verifying CILApp.exe

The only problem with PEVerify is… it does not support .NET Core.

What for .NET Core then? There is ILVerify, a cross-platform, open source counterpart of it developed as a part of CoreRT runtime (although it supports analyzing both .NET Framework and .NET Core). Currently, to have it working we need to compile the whole CoreRT (How to run ILVerify? issue #6198) OR you can use unofficial Microsoft.DotNet.ILVerification package to write your own command line tool (inspired by the original Program.cs).

So, nothing officially supported and shipped with the runtime itself, yet. And BTW, there is ongoing process to make Roslyn IL verification fully working as well.

Sidenote

The previous example was a little simplified because ConsumeString(string) called a virtual get_Length method on a sealed string type, so it was aggressively inlined. If we experiment with regular virtual method on a not sealed type, things become more intermittent because now the call is using virtual stub dispatch mechanism. In the following example (again, if rewritten to CIL), how Consume will behave depends on what we have passed as an argument and where the pointers of VSD will follow (most likely, triggering access violation).

class Program
{
   static void Main(string[] args)
   {
      var s = "Test";
      var o = new object();
      var c = new C();
      Console.WriteLine(Consume(s)); // Works but returns 'random' values
      Console.WriteLine(Consume(o)); // AccessViolation
      Console.WriteLine(Consume(c));
   }
   [MethodImpl(MethodImplOptions.NoInlining)]
   static int Consume(C c) => c.Calculate();
}

public class C
{
   public int F = 100;
   public virtual int Calculate() => 2 * F;
}

class Program

{

static void Main(string[] args)

{

var s = "Test";

var o = new object();

var c = new C();

Console.WriteLine(Consume(s)); // Works but returns 'random' values

Console.WriteLine(Consume(o)); // AccessViolation

Console.WriteLine(Consume(c));

}

[MethodImpl(MethodImplOptions.NoInlining)]

static int Consume(C c) => c.Calculate();

}

public class C

{

public int F = 100;

public virtual int Calculate() => 2 * F;

}

Conclusions

if you do write in CIL, to have more power in hands (like using Reflection.Emit, manipulate CIL fore the code weaving or any other magic like the whole Unsafe class), please be aware of the difference between validation and verification. And verify your assembly on your own, as JIT compiler will not do it!
if you do want to trust your app FULLY, run IL verification before executing it. Probably it could be even added to you CI pipeline as an additional check – you may trust your code but not someone else code (and the code modified by the tools you use). And yes, it is not straightforward currently in .NET Core case.

Mobius – .NET runtime running on .NET Core

April 7, 2020 by Konrad Kokosa·12 Comments

.NET application is “just” a piece of CIL bytecode to be executed by the .NET runtime. And .NET runtime is “just” a program that is able to perform this task. It happens that currently .NET Framework/.NET Core runtimes are written in C++. I am also fully aware of CoreRT that was .NET runtime with many parts rewritten to C# (like type system) but still, crucial parts (including JIT compiler and the GC) were left written in C++.

But what if we write .NET runtime as… .NET application? Is is possible at all? I mean, literally no native/C++ code, everything running as .NET Core application written in C#? Does this sound like kind of inception and infinite recursion? It would require running one .NET runtime on the top of another .NET runtime, right?

I decided to check it out and that’s how Mobius runtime idea has been coined! Yeah, I know it sound strange and I do not expect it will be anything close to production ready thingy in the nearest century. I am fully aware of the amount of code needed to be written to make full .NET runtime. However, I found it interesting to validate such idea and I find it small usages as well. Imagine a NuGet package with the separate runtime that you can add to your application 😉

.NET Memory Management posters

August 13, 2019 by Konrad Kokosa·0 Comments

In short words, I’ve prepared two posters about .NET memory management. They provide a comprehensive summary of “what’s inside .NET GC”, based on .NET Core (although almost all information is relevant also for .NET Framework).

The first shows a static point of view – how memory is organized into segments, generations, what are the roots and etc.:

The second shows a dynamic point of view – how GC threads are working and what GC modes are available:

You can download them for FREE in vector PDF format from my https://prodotnetmemory.com site. Take it and print it!

OutOfMemory and IT Startup card game prototypes available!

July 15, 2019 by Konrad Kokosa·5 Comments

2 Developers from Poland join forces to publish their IT-related card games: from Devs to Devs – OutOfMemory and IT Startup!

Each of us already has a published book and now we want to share some knowledge with fun games! Remember all the original 151 Pokemon names? How about playing a game that lets you remember something useful: like what technologies are beneficial to learn to be a better Developer! One of the games is already published in Poland and sold over 3k copies (so we how already some publishing know how). Now we want to start a company and publish 2 of our IT related card games worldwide in English.

Have fun while playing our print and play prototypes!

We plan to publish the games as one company on Kicktarter in Q1 2020.