Been doing some research to figure out all the *significant* runtime changes that have happened since the .NET Core CLR was first open-sourced (github.com/dotnet/coreclr…), so here's a list 👇 (if I missed any out, please let me know!)
First up, the work needed in the runtime to make the (fast) Span<T> possible, which involved the GC, JIT and VM, see github.com/dotnet/coreclr… and github.com/Microsoft/dotn… (of course, there was a whole lot more work done in CoreFX to add Span<T> overloads to many different APIs)
In addition, to support Span<T> the runtime needed to be made aware of 'ref-like' types github.com/dotnet/csharpl… and github.com/dotnet/coreclr…
Next up 'Tiered Compilation' blogs.msdn.microsoft.com/dotnet/2018/08… which is part of a larger 'Code Versioning' strategy github.com/dotnet/coreclr…, some low-level changes were needed, e.g. github.com/dotnet/coreclr… and components such as Profiling and Diagnostics had to be made aware of it
Of course, there was a whole lot of work done to enable 'Cross Platform' support, e.g. Unix github.com/dotnet/coreclr…, FreeBSD github.com/dotnet/coreclr… and Mac OSX github.com/dotnet/coreclr…. Interestingly, many of these contributions were made by the Community, not Microsoft Devs
Following on from that, there has been a significant amount of work to support new CPU Architectures, e.g. ARM64 github.com/dotnet/coreclr…, ARM32 github.com/dotnet/coreclr… and others github.com/dotnet/coreclr…
Another big feature that needed runtime changes is 'Hardware Intrinsics' github.com/dotnet/coreclr…. You can read more about how it was implemented in the excellent post blogs.msdn.microsoft.com/dotnet/2018/10… and there's a nice 'Design Doc' available github.com/dotnet/designs…
Next 'Default Interface Methods' github.com/dotnet/csharpl… which seems like it's a compiler feature, but has needed significant runtime changes to support it github.com/dotnet/coreclr…
Next 'Performance Monitoring and Diagnostics' (including 'cross-platform'), which is arguable more of an umbrella feature, but it's involved a lot of work github.com/dotnet/coreclr…. You can see the goals and aims in these docs github.com/dotnet/coreclr… and github.com/dotnet/designs…
Now some less well-known, but still significant features, first 'Ready-to-Run' Images github.com/dotnet/coreclr… which are being used (or will be used) by Bing blogs.msdn.microsoft.com/dotnet/2018/08…
In addition, there were changes made to enabled the GC to be plug-gable, in the 'Local GC' project github.com/dotnet/coreclr…. You can see this in action in tooslowexception.com/tag/garbagecol… and tooslowexception.com/zero-garbage-c…
Almost there, next is 'Unloadability', i.e. "Support for unloading AssemblyLoadContext and all assemblies loaded into it." github.com/dotnet/coreclr…. This involves a large amount of significant, low-level changes as it involves many components, e.g. look at github.com/dotnet/coreclr…
Last, but by no means least there are 'AssemblyLoadContexts' themselves, see github.com/dotnet/coreclr…
That's all folks, if I've missed out any *significant* runtime changes in the CoreCLR repo, please let me know?
