Just-In-Time (JIT) compilation
As stated above, the Just in time compiler is a facility that is invoked by the CLR to convert the IL into machine code. The .NET framework assemblies (*.dll or *.exe) files cannot be executed by the target processor unless it is converted into native code. When the Assembly is loaded the method calls are invoked for compilation into native code. Since this is done just when the method needs to execute, it is called Just in time compilation. When the JIT is invoked for the first time there is an overhead or performance penalty, since the assembly is converted into its Native code or image using the Native Image Generator (Ngen.exe). All subsequent calls will load faster as the Native image alone is invoked thereafter from the Native image cache.
Significantly, the IL can coexist with the machine code in the application. This feature also enables the developer modify the code or add to the code even when the application is actively deployed. This functionality provided by JIT makes the .NET framework an efficient, agile and powerful means of application development.
Assemblies, native assemblies, and the Global Assembly Cache (GAC)
The primary unit of deployment is the assembly. The assembly is used by the .NET CLR as the smallest unit of deployment; version control; security; type grouping and code reuse. An assembly will consist of a manifest and one or more modules or files. It can be defined as a logical DLL that contains a manifest, type metadata, MSIL and resources. Assemblies can be application private or shared. Private assemblies are restricted to use in a single application whereas shared assemblies can be used across applications. Private applications also reside within the application folder while shared assemblies reside in the common area-- GAC(Global Assembly Cache). They must have a globally unique name.
The existence of the manifest within the assembly makes it self descriptive. It can be viewed by the IL Disassembler (Ildasm.exe) which is part of the .NET framework SDK.
The assembly is identified by the manifest. It defines security requirements, lists other interdependent assemblies and all the types and resources exposed by the assembly. Localized resources exposed by assemblies and targeted by the application contain a default culture (language, currency, date/time format etc).
The manifest contains several sections. Identity, Referenced Assemblies, file list and Custom Attributes are some of the important sections of the manifest. The Identity section as the name suggests, identifies the assembly. It contains a .assembly directive. The version directive specifies the version of the assembly, so that the CLR identifies the different versions of an application. The Identity section contains a strong name for shared assemblies and a public/private encryption key is used to distinguish between assemblies of the same name. The Identity section also optionally contains the Culture which defines the country and language of the assembly target. The .locale directive is used for this purpose and the Culture-Neutral assemblies can be used by any assembly. The Referenced Assemblies section of the manifest provides a reference to all the assemblies used in an application.
Comparison of VB.NET, C#, and J#
The .NET framework architecture has made the language of coding immaterial to the final output. All languages also have equal access to all development capabilities and revolve around the .NET classes. The language syntax, operations etc look similar in all the languages of this group. Moreover, code can be shared by all .NET languages and so a class made in C# or J# can be used in VB.NET and vice versa.
In this context choice of language is no longer significant. Finally, all languages are transformed by the compiler into Microsoft Intermediate language. It is the programmer’s familiarity with the language that makes it material whether he is coding in VB.NET or C# or J#. However, the option settings in the compiler will have to be set to the language of coding before the compiler is used.
The speed of performance of the compiler will also vary with the language being compiled. For instance C# compiles faster than VB.NET. Subject to the above observation, the features of the languages will be dicussed in the next tutorial.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment