Skip to main content

A glance at the insides of the CoreCLR

So these past days I was kind of bored and also I wanted to prove to myself that I can take a serious software project and the understand it. I heard so many things about the CLR like it was some kind of alien technology that no one could understand. I saw that it as a challenge and decided to see if it's really like that.

And the rumors were true in a way. The CLR is a marvel of software engineering. It is actually made out of multiple systems with one central system that glues them together. That central system is called the "Execution Engine". I think it's what controls and manages the execution of the program. It is for example responsible for stopping the execution of the program when the garbage collector starts to do it's job.

Actually the garbage collector sends a command to the execution engine to stop the execution of the program. Yes, the garbage collector is another system just like the execution engine. It is actually pretty interesting to see how the garbage collector actually works. The thing is that the code is compiled to native code when the program is executed. And the garbage collector has to somehow make sense of that compiled code in x86 assembly. I think it accesses the variables and objects through a high level interface that takes that compiled x86 code and translates it into something that the garbage collector can use. For example, local references stored on the stack need to be somehow accessed by the GC but it's all compiled code and you somehow need to know where inside the original IL code the execution stopped so you can see what references are available. Those references are used as roots to keep objects alive.

Not only that but I think the execution engine is also responsible for probing variables which is used by the debugger. I saw that there are some structures, C++ structures that tells the location of some variables. I think these are used to show in the locals window in Visual Studio the variables visible in the current scope.

I also think that the execution engine is responsible for debugging too. It can stop the execution of the program or let the program run until a certain point in the code is reached.

Another system inside the CLR is the jit compiler. I think all the IL instructions inside a method are added inside a tree, actually a GenTree that is then modified for specific optimizations. One of these optimizations that I noticed is "folding". I think this means that if we add some constant values inside the code, then before compiling those IL instructions to native code, the constant values are added together and replaced with that result. For example if you have inside the code an expression like "x+4+5" it will get transformed into "x+9".

After all the optimizations are done, I think that tree is traversed by the compiler and x86 code is generated.
Labels:

Comments

Post a Comment

Popular posts from this blog

Some software development common sense ideas

 I haven't really written here in a long time so it's time to write some new things. These are just some random common sense things that seemed to short to write about individually but seem really interesting and useful to me or other people 1. There is nothing fixed in software development, all things vary by circumstances and time Remember the documentation that didn't seem that important when you started the project, well after a couple of years one the application has grown and become really complicated, no one actually knows everything about the application anymore. So now you really need that documentation. What happens if you suddenly need much more people to develop the application because of some explosive growth? Without documentation, new developers will just look at the application like they look at a painting. This actually happened to me. Maybe in the beginning of a project, a technology really helped you a lot but as the project grew, it started making things...
3 comments
Read more

My thoughts as an experienced developer in this field.

To be honest, I would have never guessed that      I would end up saying these these things, especially jn the beginning of my career. As you become more experienced, you kind of get to see everything and you become less impressed by new things. Honestly there is some sort of repetitiveness in this field and we kind of like to reinvent the wheel quite often, because well, we become a bit too easily bored. Take for example how the web looks now, a lot of it has been borrowed from other places, mostly desktop development, especially the parts about making custom reusable components.  Or from older frameworks, like state management in the UI which actually was first properly implemented in Asp .Net Webforms, as far as I know, something like 20 years ago, where you used to have the dreaded view state.  But most likely something similar existed before that too. I was not that surprised when React adopted initially this idea. Or even less surprised when hooks where in...
Post a Comment
Read more

Some of my realistic thoughts about technical debt

 Lately I have been kind of stumbling into a couple of issues related to technical debt, a bit more than I really wanted to so I guess it's time to write about this some things. Also, some ideas about this have been brewing in the back of my head for some time now so now is the moment to write all of it. The first thing that comes in my mind when thinking about technical debt is how big is the area affected by it. In the best of circumstances it might affect just a specific area in an application, usually a specific feature because of bad implementation, unclear requirements, various disruptions, tight deadlines or many other reasons. This kind of technical debt usually doesn't have a wide ranging negative impact because it's local to a specific area. The only concerning case it when it affects a critical feature that it used often and updated often, even by other features. On the next level, several areas of an application might be affected by some technical debt issue. Th...
Post a Comment
Read more