At 12:14 PM 1/10/2005, Swaminathan S R wrote >Thanks for the reply. > >I have a couple of questions from your answers :: > >1. If the DLLs are not loaded, then why does each process consume equal >amount of memory? > I took the process wise memory consumption (using the >"tasklist") and two instances of the same exe were occupying almost same >quantum of memory.
The memory consumption of each task is the consumption of that task without regard to other tasks. For example, if each task uses the same 5mb DLL, it would be wrong to say that the first one uses 5mb and then second one 0 -- if the first task ends, the second then uses 5mb. Also, both EXEs and DLLs (each are "executables") are "mapped into" memory -- they are not read in their entirety. Only the pages of the executable that are actually needed (and sometimes nearby pages as the result of disk clustering and cacheing) are read into memory. Look at what happens to the total memory used if you load a second or 3rd copy of VS.NET -- it doesn't go up by as much as you'd think. Nor does closing one of them free as much memory as you'd think. I am not aware of a tool that does a good job of showing information about memory that's shared by multiple tasks, or of showing what portions of an executable have actually been read into memory. (I wrote nothing more.) >2. I was trying to visualize the CLR components as service(by comparing >it with windows services running under svchost.exe). Where is my >comparison wrong? > >- Swami. > >-----Original Message----- >From: Steve Johnson [mailto:[EMAIL PROTECTED] >Sent: Monday, January 10, 2005 7:59 PM >To: [email protected] >Subject: Re: [ADVANCED-DOTNET] Question on CLR > > >Swaminathan S R wrote: > >> I have a doubt in the way CLR has been conceptualised. In my >> uderstanding the CLR (and its services)is specific to a given process. > >> What i mean here is: if i start two .NET EXEs' separately the >> mscoree, mscorlib, and other related DLLs would be loaded into each of > >> the EXEs process, right? Couldn't the CLR been designed as a service >> so that this can manage all the .net applications? > >First, only one copy of the modules is actually in physical RAM. This >is not unique to the CLR, but it's how the Windows loader works. For >each process that loads a module that is already in RAM, the OS simply >maps the module into that process's address space. > >This leads right into why it wouldn't work to implement the CLR as a >service. For one thing, each process has it's own address space and >that address space cannot be manipulated/managed from another process. >I'm sure there are even more good reasons that the CLR is not >implemented out-of-process, but this is the biggest reason. Since the >CLR is largely a memory-management system, it wouldn't do much good if >it were out-of-process and out-of-reach of the memory it's trying to >manage. :) > >-- >Steve Johnson J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
