
Guide to the CoreCLR Source Code - adamnemecek
http://mattwarren.org/2017/03/23/Hitchhikers-Guide-to-the-CoreCLR-Source-Code/
======
giancarlostoro
>> Just over 2 years ago Microsoft open-sourced the entire .NET framework,

Except they open-sourced a new .NET stack, not really the entire .NET
Framework, .NET Core and .NET Framework are similar but not fully backwards
compatible. I've been porting .NET Framework code to .NET Core and depending
on how specialized your project is you may not always find the same libraries
supporting your project. A project that perfectly compiles with .NET 2.0 will
not just compile for .NET Core, at least not as easily as using a .NET
Framework 2.0 project in .NET Framework 4.6. I love Microsoft and .NET but I
think Core is executed poorly. You also have EntityFramework vs.
EntityFramework Core which lacks features from EF which were deemed "unused"
which bites some people in the face.

~~~
manigandham
.NET Standard/Core 2.0 will add back many APIs. It'll be the real release of
the newer framework, similar to how the original .NET Framework took until v2
to get things into shape.

.NET Standard is all about compatibility - so you can use that to determine
which framework you can/need to use. However .NET Core is a distinctly
designed for cross-platform reach so it will be a break from .NET Framework in
some ways - this is just a given, otherwise they would've just released
another .NET Framework version instead of doing all this.

~~~
giancarlostoro
Yeah I know this, and hopefully they get it right, unfortunately I'm not there
yet. To be fair .NET Core has been great otherwise, I have been able to
develop from Ubuntu (used Sublime Text, which I didn't use the plugins since
they seem abandoned or something) gave Rider a try but it was buggy at times.
I wish Microsoft releases either a plugin for MonoDevelop, or "Visual Studio
for Linux" at some point.

~~~
WorldMaker
Have you tried VS Code yet? It's not a full "Visual Studio for Linux", but in
terms of intellisense and debugging it has a lot more than you might expect.

~~~
giancarlostoro
I've used it, but I never took the time to figure out how to make it run code
/ debug and I like how fast Sublime Text / CudaText are by comparison.

~~~
jyrkesh
Me too, but I've been trying out newer builds and Code is getting a lot faster
than it started out

------
tombert
I find these runtime VMs fascinating to ogle at after looking at how Erlang's
GC worked. I think you have provided me reading material for this weekend.

~~~
matthewwarren
Glad to be of service!!

BTW if it's reading material you want, you should also check out me other post
'Research papers in the .NET source'
[http://mattwarren.org/2016/12/12/Research-papers-in-
the-.NET...](http://mattwarren.org/2016/12/12/Research-papers-in-the-.NET-
source/)

------
cm2187
gc.cpp, 37,000 lines of code. And some want to remove Regions from the .net
framework!

~~~
UnoriginalGuy
Regions aren't a .Net Framework feature, they're a language feature.

There's absolutely no reason they should be in C# and encourage bad coding
practices (like overly long .cs files). Even if you need all your code in a
single class, you can shard that class across several .cs files to make
organisation and maintainability easier.

Regions are just a crutch people use to allow them to create 10K+ line .cs
files that will eventually become a maintainability nightmare (as well as
making merges/check-ins/finding things more annoying in general).

Only region I'll use is the built DEBUG one and I only use that to create:

    
    
         private bool IsDebug()
         {
         #if DEBUG
           return true;
         #else
           return false;
         #endif
         }
    

Stackoverflow answer for why regions are bad:
[http://softwareengineering.stackexchange.com/questions/53086...](http://softwareengineering.stackexchange.com/questions/53086/are-
regions-an-antipattern-or-code-smell)

~~~
taco_emoji
I agree about regions, but `#if` et al are preprocessor directives, not
regions. They actually influence how your code is compiled.

------
eiji
What's with the Smalltalk portion? Anyone knows why that is?

~~~
desdiv
There's no actual Smalltalk code in there. It's just a Github display bug.

[https://github.com/dotnet/coreclr/search?l=smalltalk](https://github.com/dotnet/coreclr/search?l=smalltalk)

------
youdontknowtho
The GC Sample is really interesting.

~~~
matthewwarren
Yeah it's great, I learnt so much about the GC from looking at that sample.

BTW if you want a bit more info on it, I wrote a whole blog post, see
[http://mattwarren.org/2016/02/04/learning-how-garbage-
collec...](http://mattwarren.org/2016/02/04/learning-how-garbage-collectors-
work-part-1/)

------
NeverTrump
I want to note something that my interest some:

The second biggest fear which made Sun sue Microsoft was that when MS licensed
Java, their VM was faster than Sun's. Microsoft is (was?) the king of JIT.
Technically biggest since if theirs was faster, they wouldn't have cared for
Microsoft's anyway. Even now CLR is generally considered much faster than JRE.

I don't know how Chakra compares against v8 but then it also depends on what
makes money for MS.

~~~
kuschku
> Even now CLR is generally considered much faster than JRE.

That’s... not really true. JRE’s HotSpot is much faster than CLR, even today.

I’d be interested to see benchmarks proving your argument, because basically
every benchmark out there proves you wrong.

Sun’s HotSpot does recompilation and profiling, to reoptimize depending on use
case, while CLR only JIT’s once, so the base performance is very low. This is
also why HotSpot can reach better-than-C performance in some cases (because it
can optimize at runtime for actually taken code paths, and jump to interpreted
code for rarely taken paths), while .NET (and native code) can not. (This is
what gives HotSpot the name – it recognizes hot spots, and swaps them out for
more and more optimized versions at runtime)

~~~
chrisseaton
I tried to find any studies because the claim surprised me, but I didn't find
any, so I wasn't going to try to refute that without any data.

But I can say that the number of research papers around the JIT in the JVM is
probably and order of magnitude more than around the CLR. Someone else linked
to 'Research papers in the .NET source', and guess what? Several of them are
really JVM papers, talking about how they've used the same technique.

