Re: Is There a Way to Remove a Module From Memory"
- From: "Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 5 Jun 2007 11:17:24 +0100
As with all Windows processes, the compiled code in an exe/dll/ocx is
"mapped" into virtual memory. In other words, pages of the process virtual
address space are pointed at areas in the relevant file, and the code is
paged in (via the VMM) as it's used. These virtual pages are set up as soon
as an exe is launched, but for a dll/ocx it occurs only when that component
is first accessed. This means that the exe is always part of your virtual
address space, but not all of it resides in RAM (physical memory) at any
given time. It also means that a dll/ocx may not even be in your virtual
address space. Once dll/ocx components are loaded, the VB runtime may decide
to unload them from your virtual memory if they're no longer being accessed.
The Project property 'Retain in Memory' overrides this, and is very
important in multi-threaded projects.
As for classes, the primary memory for class variables and Static variables
in the classes methods, are allocated as a single aggregate chunk from the
heap, for each instance of the object that's instantiated. Secondary memory
(i.e. for variable-length strings, arrays and referenced objects) are
allocated separately from the heap. All of this memory is returned to the
heap when the associated object is destroyed. This isn't the same as being
unloaded from either physical or virtual memory though. It simply means the
heap manager then has control over that virtual memory, and can decide to
reuse it later. Modern heap managers also try to decommit significant areas
of contiguous virtual memory in their free zones because it's more efficient
to reuse it as "demand zero" pages rather than risk paging in all the old
data debris from their last usage.
As for Modules, I believe that their primary memory (i.e. excluding
String-values/Array-values/referenced-objects) is allocated as a single
aggregate when the relevant component (exe/dll/ocx) is first initialised,
and separately for each thread on which it's initialised. Hence, if a
Standard EXE starts up then the total aggregate of primary data for the
variables in its Modules (and Static data in Module procedures) is allocated
at that time. The same happens for a dll/ocx when it is first accessed. For
a multi-threaded ActiveX exe, that aggregate is allocated separately for
each of its apartments/threads as they initialise. For a dll in a
multi-threaded environment (e.g. ASP), the aggregate is allocated separately
as each apartment accesses the dll
Tony Proctor
"Steve Gerrard" <mynamehere@xxxxxxxxxxx> wrote in message
news:w_idnZKqycL3o_7bnZ2dnUVZ_uqvnZ2d@xxxxxxxxxxxxxx
space
"Larry Serflaten" <serflaten@xxxxxxxxxxxxxx> wrote in message
news:e5cbSVipHHA.5008@xxxxxxxxxxxxxxxxxxxxxxx
Trying to find relavent material is getting harder and harder due to
everything
switching over to .Net, but there is this:
http://msdn2.microsoft.com/en-us/library/253b8k2c(VS.80).aspx
Like the rest of a program's code, DLL code is mapped into the address
onlyof the process when the process starts up and it is loaded into memory
usedwhen needed. As a result, the PRELOAD and LOADONCALL code attributes
longerby .def files to control loading in previous versions of Windows no
entirehave meaning.
As it says, "Like the rest of a program's code..." which would mean the
i.e. anprogram's modules are loaded on demand.
I think "loaded on demand" is here referring to a machine code module,
executable or a dll, not a breakdown of the contents by original sourcecode
.bas module. Also, I think the "like the rest of a program's code", i.e.the
executable, applies to the "mapped into the address space of the process"part,
but not the "loaded into memory when needed" - since it is needed rightaway, if
the executable is going to start.if
That is not how I understood it. How would VB support compile on demand
thatthe whole program had to be loaded when it started up?
http://msdn2.microsoft.com/en-us/library/aa241763(VS.60).aspx
The default in Visual Basic is to compile code on demand. This means
calls it.there
may be code in your component which is not compiled until the client
when
Compile on demand, and the rest of the above link, is about what happens
debugging in the IDE. It does not apply to compiled executables and dlls.memory
AHA! I found the page I had seen before:
http://msdn2.microsoft.com/en-us/library/aa716325(VS.60).aspx
Visual Basic loads modules on demand - that is, it loads a module into
aonly when
your code calls one of the procedures in that module. If you never call
sourceprocedure in a
particular module, Visual Basic never loads that module. Placing related
procedures in the
same module causes Visual Basic to load modules only as needed.
Again, "particular module", in my opinion, is referring to a .dll, not a
code .bas module. I simply can't imagine there would be any mechanismincluded
in non-debug compiled .exes and .dlls, for separately loading code bysource
code .bas module.
.
- References:
- Re: Is There a Way to Remove a Module From Memory"
- From: Ralph
- Re: Is There a Way to Remove a Module From Memory"
- From: Larry Serflaten
- Re: Is There a Way to Remove a Module From Memory"
- From: Steve Gerrard
- Re: Is There a Way to Remove a Module From Memory"
- From: Larry Serflaten
- Re: Is There a Way to Remove a Module From Memory"
- From: Steve Gerrard
- Re: Is There a Way to Remove a Module From Memory"
- Prev by Date: Re: Rip Off
- Next by Date: Re: How to get my program's file date?
- Previous by thread: Re: Is There a Way to Remove a Module From Memory"
- Next by thread: Re: Is There a Way to Remove a Module From Memory"
- Index(es):
Relevant Pages
|
Loading
