4 ms·
Before the CLR was open sourced you could investigate how things were implemented by using decompilers on the MSIL code or later shared source, but but investga
by MarkSweep 10y ago
Before the CLR was open sourced you could investigate how things were implemented by using decompilers on the MSIL code or later shared source, but but investgations often stopped at a InternalCall just as things started to get interesting. Now you can see the whole story of how abstractions are implemented part in C# and part in C++ when the runtime needs to "bend the rules" of what C# would normally allow. The corert[0] project is interesting because a larger portion of the run is implemented in C# (or as compilation passes instead of runtime code generation). For example, you can find exception dispatch and type casting implemented in C# there [1].
One example from the article that may be a little off is getting the length of string. It looks like the call to string.get_Length is probably replaced with a JIT intrinsic[2]. The importer then turns that intrinsic call into a GT_ARR_LENGTH[3] node that is eventually lowered into something like[4]:
*(stringAddr + offsetOfStringLengthField)
It's a bit more complicated than that, as there are several references to GT_ARR_LENGTH in various optimization passes.
[0]: https://github.com/dotnet/corert/ https://github.com/dotnet/corert/
[1]: https://github.com/dotnet/corert/tree/master/src/Runtime.Base/src/System/Runtime https://github.com/dotnet/corert/tree/master/src/Runtime.Bas...
[2]: https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa1810fde0c7ffb842fa31b/src/vm/ecalllist.h#L226 https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa18...
[3]: (warning, big file) https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa1810fde0c7ffb842fa31b/src/jit/importer.cpp#L3119 https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa18...
[4]: (warning, big file) https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa1810fde0c7ffb842fa31b/src/jit/flowgraph.cpp#L8828 https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa18...
- kaushiks 10y agoNot necessarily. As long as it wasn't related to the JIT or the GC, one could always look up the SSCLI (ROTOR) code to understand how something was implemented. https://en.wikipedia.org/wiki/Shared_Source_Common_Language_Infrastructure https://en.wikipedia.org/wiki/Shared_Source_Common_Language_...
- MarkSweep 10y agoThat's a good point. It's fun to diff Rotor and CoreCLR to see how much has changed and what has stayed the same. The JIT and GC seem to not match up at all, but good chunks of the vm folder match up nicely.
- matthewwarren 10y ago> Before the CLR was open sourced you could investigate how things were implemented by using decompilers on the MSIL code or later shared source, but but investgations often stopped at a InternalCall just as things started to get interesting. Now you can see the whole story of how abstractions are implemented part in C# and part in C++ when the runtime needs to "bend the rules" of what C# would normally allow. Yep, that's a large part of the motivation for me writing this post, although after looking at the source, I then went back to WinDBG and the Microsoft Symbol Server, which I could've done before it was open sourced!! Thanks for the clarification on what the JIT is doing to optimise the string length. So far I've not managed to find the time to look at it's source, it took me long enough to find my way round CoreCLR! In the post, I sort-of hand-waved about what was happening there, it's nice to have some more concrete details.