.NET Programming Monthly Issue 2

0x00 Building a self-contained game in C# under 8 kilobytes

This article came out as an experiment to find out just how small a useful self-contained C# executable can be.
For a C# app to be self-contained, it needs to include the runtime and all the class libraries it uses. It’s a lot of stuff to fit into the 8 kB.
The 8 kB game is a clone of the Snake game. This post introduces how to shrink the game from 65 megabytes to 8 kilobytes in 9 steps.
A fixed array is an array whose individual elements are a part of the struct. 1
IL Linker is a tool that shipped with .NET Core 3.0 — the tool removes unused code from your app by scanning the entire program and removing assemblies that are unreferenced. Be limited by the size of the CoreCLR runtime itself — coreclr.dll — at 5.3 MB.
The only .NET runtime where this is possible is CoreRT. It’s not a virtual machine like CoreCLR or Mono — the CoreRT’s runtime is just a set of functions that support ahead of time generated native code produced by CoreRT’s ahead of time compiler.2

A common misconception is that the only difference between just-in-time and ahead-of-time runtimes is in the timing of native code generation. You can find the difference between jit and aot compilation at the end of the article.
A just-in-time compiled .NET runtime will typically have a step called “type loading” where it builds an alternative representation of each type into a runtime allocated data structure.
It’s quite clear that it’s not just the code, but also the representation of metadata in an IL assembly that is different from what we need at runtime. The file format of the IL assembly is not what we would come up with if AOT compilation was our objective. The fact that the mainstream .NET runtimes use the IL format metadata even in AOT mode makes sense from an evolutionary perspective: these runtimes are built around the concepts represented in the IL metadata because they started as just-in-time runtimes.
CoreRT3 is an experimental cross-platform open source .NET runtime specialized for AOT compilation.
The IL file after aot in CoreRT removes a lot of extra information.
The main performance benefit of ahead of time compilation comes in the form of startup time.4

This post is a little out of date. And now there are dots(job system, ecs and burst) in Unity. But it’s still helpful for these who wants to use Async/Await in Unity.
The key point is to use a dispatcher that can run the UnityEngine calls on the main thread to avoid some exceptions when call an Unity function on the other thread.

The post is an instruction demostrates how to run SQL Server on MacOS directly through Docker, run queries and other commands via the sql-cli command line tool, and introduces some GUI tools(such as Azure Data Studio,DBeaver).
Talk about some limitations for SQL Server on MacOS, such as linux release doesn’t include many of the extra services that are available in the Windows release.5 And the SQL Server Management Studio is not available on Mac or Linux.

It’s a design doc from .netcore runtime about string deduplication.
The doc introduces the duplicated strings issue, the history of the string deduplication feature and the detail of the design.
The runtime will create a deduplicated thread to do the work.
Detection of duplicated strings is done by looking into a hash table. The key into this hash table is the hash code of the content of a string.
Only strings allocated on the managed heap will be considered for deduplication. And only the ones that live in the old generations, meaning gen2 an LOH, will be considered.
Compatibility and Potential future work.

The post discussed something “internal”. Although a bit dated. But still very interesting.
The internal process of the debugger and CLR after the user clicks the debug button. Adding the breakpoint. Running to hit the breakpoint. Notifying the debugger and so on. Check it out.

Do you know that JIT-x86 can’t apply the inlining optimization for a method that contains the starg IL-opcode? The implementation of Decimal is a hack to avoid this situation.
JIT-x86 can’t apply the inlining optimization for method that contain the starg orldarga opcodes regardless the MethodImpl attribute.

This greate post is out of date (CLR 2.0). But it’s still helpful to understand the internals of .Net types from a CLR perspective.

This article talked about .NET’s object memory layout and how objects lay in memory and about Method Table and EEClass and how Generics affect them and how they work under the hood, and what optimizations CLR performs to keep them efficient.

These are some tips from author’s experience in optimizing Hagar’s performance. Most of this advice is applicable to other types of libraries or applications.