RE: [dotNET] RE: [Dotnet-sscli] Loading behavior

["Jim Miller (COM+)" <jsmiller@microsoft.com>]

Let me add that "class loading" and "module loading" are really about making internal representations, used by the JIT compiler and Execution Engine, from information that was already present in memory in the format used for a PE File.  The PE formatted information might come from mapping in a file (DLL or EXE) or it might have been created by reflection emit or read from a stream or whatever.  While this file format is fine for storage and transmission, it isn't tuned for in-memory use at runtime -- that's where things like hash tables of assemblies, etc., become important.
  
-----Original Message-----
From: David Stutz [mailto:davidstu@microsoft.com] 
Sent: Friday, July 05, 2002 11:58 AM
To: Albrecht Wöß; dotnet@di.unipi.it; dotnet-sscli@di.unipi.it
Subject: [dotNET] RE: [Dotnet-sscli] Loading behavior


There are three levels of loading in the SSCLI, when loading from disk.  First the PE file itself is loaded and checked for structural consistency (see pefile.h).  The PE file contains enough information to locate the metadata and the IMAGE_COR20_HEADER, which are key to the next stage.  Next, the assembly is loaded using an appDomain and checked for integrity (strong name, etc.)  Take a look at BaseDomain::LoadAssembly in appdomain.cpp.  Finally, the type is loaded, using the assembly's class loader to create an EEClass and MethodTable pair.  The first time that code is called, the JIT compiler will be brought in and native code will be produced and run.  You might want to trace through ClassLoader::ExecuteMainMethod in clsload.cpp to see all of this in action.  A single method call will cause other types and assemblies to be loaded as needed.

One thing that might be confusing is that there is a service (in the clr/src/fusion directory) called "fusion" that is essentially about locating and loading *files* (and includes all of the config file stuff).  In the vm directory, the logic is about loading assemblies and modules.  

The dynamic stuff may also be confusing - while the common path is to load from disk, it is also important for compilers and tools to be able to emit assemblies, and so the codepaths for dynamic assemblies and for file creation also exist.  Dynamic assemblies are discussed in the SDK documentation.  You can use them to create on-disk assemblies programmatically, to create new in-memory assemblies that can be run immediately, that kind of thing.

Hope this is helpful - happy spelunking!

-- David Stutz


-----Original Message-----
From: Albrecht Wöß [mailto:woess@ssw.uni-linz.ac.at] 
Sent: Friday, July 05, 2002 5:49 AM
To: dotnet@di.unipi.it; dotnet-sscli@di.unipi.it
Subject: [Dotnet-sscli] Loading behavior


I would like to know which parts of the SSCLI or CLR are responsible for 
what kind of loading task:

- loading modules:
These are the files on the disk, so basically all that can actually be 
"loaded" are modules.
Is there a separate module loader or does the class loader do this?

- loading assemblies:
This comes down to loading the module containing the manifest and 
extracting the manifest metadata from it, right?
Is there a separate assembly loader or only a module loader or is it all 
in the class loader?

- loading classes (types):
Since the units of loading have to be the modules (which correspond to 
files on disk) what is meant by dynamic class loading in the CLR? i.e. 
what does the class loader do when a type is used for the first time, 
but it is contained in a module that has already been loaded. Isn't the 
code for the type already in memory?

Probably it is all obvious and I'm just a little confused, but if 
someone could explain the details to me, I would be very grateful. Or at least point out the (exact!) places (=files and even methods!) in 
the shared source code where I could look for some answers.

Thanks

Al

--
Albrecht Woess
Johannes Kepler University Linz


_______________________________________________
Dotnet-sscli mailing list
Dotnet-sscli@di.unipi.it http://mailserver.di.unipi.it/mailman/listinfo/dotnet-sscli
_______________________________________________
dotNET mailing list
dotNET@di.unipi.it http://mailserver.di.unipi.it/mailman/listinfo/dotnet