Understanding the Common Language Runtime

In Chapter 2, the terms "managed" and "unmanaged" were introduced. Also in that chapter, the CLR was (very) briefly introduced. Basically, I discussed how .NET-enabled program code was considered managed code and programming code executed outside of the .NET environment was considered unmanaged code. Consequently, the CLR is the "manager" of .NET-enabled code. The mainframe analogy offered in this earlier discussion suggested the "managing" that JES2 on the mainframe performs is similar to the managing performed by CLR on .NET. So, is there more? Yes, there is a lot more.

Having Fun with Acronyms

It is purely a coincidence that Microsoft chose the CLR acronym to describe a critical portion of .NET and that CLR happens to be the initials of my name: Christopher Lynn Richardson. If Microsoft had asked me to name this portion of .NET, they probably would have ended up with a name like "the engine of .NET." So, then we would have had an acronym like "TEN." Although that does spell .NET backwards , it would have left many developers in a state of confusion (except for those skilled in the art of ^[1] gnidaeR drawkcaB) . So, again, I tip my hat to Microsoft for their marketing genius.

 

I begin this discussion by looking at the name of the feature itself: common language runtime. Obviously, Microsoft chose that name to communicate that all .NET-enabled languages, once brought down to a "common" code form, will "run" on this virtual machine of sorts. In fact, that is the basic premise of Microsoft intermediate language (MSIL, or IL for short). Once each "high-level" language is taken through the appropriate compiler to create the intermediate language (a common denominator), the CLR then just runs the IL code without any discrimination. Understandably, some people refer to MSIL as CIL, which stands for common intermediate language. CIL is the generic specification that MSIL is based on.

There is one problem: This explanation is incomplete. To begin with, the CLR does not actually "run" the intermediate language. Does the mainframe "run" assembler code? No, the assembler code is "compiled" into machine code. The same concept applies here. The intermediate code is taken through a "compiler" that creates the machine code. The machine code is actually "run." (The compilation of IL to machine code occurs in the just-in-time [JIT] compiler.)

Cross-Reference  

I discuss the JIT compiler further in Chapter 17.

Beyond that, there is still a problem with this brief and incomplete explanation. Yes, it is important to realize that the CLR's use of IL basically opened the door for Fujitsu Software and other ISVs to create .NET-enabled compilers. And yes, the use of IL even opened the door for Visual Basic .NET (VB .NET) to stand shoulder to shoulder with Visual C++ .NET (C++ .NET) and Visual C# .NET (C#). Still, the CLR is more ”much more ”than just the topic of IL.

For a moment, let's use the legacy mainframe JES2 system software as an analogy for the CLR. Just to review, I discussed in Chapter 2 the scenario of you submitting your batch programs in the form of Jobs, JES managing the priority execution of your Job, and JES being involved in the purging of your Job from the operating system. As you know, it is not that simple.

Up to this point, I have omitted many other COBOL mainframe (batch) development concerns. When it came to management of your "code," "process," and "resources," you had decisions to make. Typically, before you got to the point of being able to process your mainframe program, you (a veteran mainframe programmer) asked yourself most of the following questions:

• Which compiler directives should I use?

• What libraries should I include when I "link edit" my program?

• How much memory will my Working-Storage Section consume ?

• Is my main program making static or dynamic calls to subprograms?

• Is my program going to be statically or dynamically called by a different program?

• Where is my compiled (binary) load module located?

• Did I remember to use a DISP=SHR on my JCL data definition statement when referring to my program load library?

• Am I going to execute my program in a JCL cataloged procedure?

• Do I need to override the default REGION allocation for memory (by Job or by Job Step)?

• When are any requested system resources going to be deallocated?

• Should I manually deallocate any system resources?

To those veteran mainframe programmers who happen to think in terms of CICS online application development, the additional following questions should be familiar:

• Does my CICS program design require me to use GETMAIN and FREEMAIN commands for explicit storage (memory) allocation and deallocation?

• Does my CICS program design require me to use ENQ and DEQ commands to explicitly reserve and release system resources?

• I want to use a temporary storage queue. Does it matter to my CICS application design if the queue is main storage or auxiliary storage?

• I want to use a transient data queue. Just how "transient" is the data that goes into the queue and what design considerations will I need to make to prepare for it?

Having gone through the exhaustive list of legacy mainframe development, perhaps you are saying, "Right, but what does this have to do with the CLR?"

Well, mainframe development ”both batch and online ”required that you actively participate in the various aspects of managing your application. Yes, the mainframe JES2 package, along with a host of other system software, was at your disposal. Basically, everything from JCL to the operating system played a part in this management . For instance, you have dealt with memory management, resource allocation, and code optimization. Can you now see where this analogy is leading? That is right. When you are developing on the .NET platform, the CLR will be there (in the background, mostly) assisting with these types of management concerns. And yes, you still have opportunities to actively participate.

Let's now move further into the CLR to review its feature set. Generally speaking, the CLR has the following features:

• Memory management through the garbage collector (GC)

• Code optimization through the just-in-time (JIT) compiler

• Process and application domain management

• Code access security

• Thread pool management

• .NET Remoting (distributed processing)

In this chapter, you will learn about the GC feature in detail. I delay discussion of the remaining features until later chapters, as shown in Table 8-1.

Table 8-1: CLR Feature Discussion

FEATURE	CHAPTER
The JIT compiler	Chapter 17
Code access security	Chapter 18
Process and application domain management	Chapter 20
Thread pool management and .NET Remoting	Chapter 20

^[1] "Backward Reading." Recall that I warned you that I would make an attempt to present this information to you in an interesting yet useful way. This is in response to my peers who always thought that it was unusual that I was able to read IBM technical manuals as if they were novels ”and not fall asleep.