Re: Compiler and How It Handles Scope

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Tony Proctor (tony_proctor_at_aimtechnology_NoMoreSPAM_.com)
Date: 08/26/04 

Date: Thu, 26 Aug 2004 10:09:10 +0100

VB's compiler isn't really "state of the art" David. However, what I'm about
to say is not really specific to VB (e.g. may apply to any language
accessing COM)

Executable code is not on any heap or stack. It is memory-mapped when the
EXE/DLL is invoked. This means that there's only one copy in physical
memory, no matter how many processes map the code into their virtual address
spaces.

When the compiler generates code for Module data, a single aggregate area is
first mapped out. All variables, whether Private or Public, are allocated
relative addresses in that aggregate data area. When the code is first
invoked, a memory area big enough for this aggregate is allocated from the
heap, and all your variables have well-defined offsets in that area. In
particular, in a multi-threaded environment (VB does support STA threading),
multiple copies of that aggregate are allocated -- one per thread. In other
words, no real distinction is made between Public/Private variables, or even
Static variables in Module procedures. They all co-exist in these aggregate
data areas, and are only destroyed when the DLL/EXE is unloaded.

With classes, a similar aggregate concept exists. However, the memory for
that aggregate is created when each instance of the class is created, and
freed when each instance is destroyed. COM objects are reference counted.
Hence, they are destroyed immediately when their reference counts go to 0.
This is sometimes called "deterministic finalisation", and contrasts with,
for instance, the .Net garbage collector which cleans up your objects at
some unspecified time after you've finished with them (i.e. when it feels
like it).

COM DLLs are generally unloaded from memory when there are no more class
instantiations from them (i.e. no more objects allocated from them), and
this includes their Module data too. I say 'generally' because there are
ways they can be prevented from unloading. The COM function
coFreeUnusedLibraries() can be used to periodically make sure unused DLLs
are unloaded. However, this calls back the DllCanUnloadNow() function
exposed by all COM objects to make sure each one really is unused. You might
want to check out the 'Retain in Memory' property you can set on VB projects
too. I'm not certain but I believe it uses the DllCanUnloadNow() mechanism
to prevent a DLL being unloaded. This is important in multi-threaded VB
environments.

            Tony Proctor

"dw85745" <dw85745@gbronline.com> wrote in message
news:EJqdnfUggobfRLHcRVn-iA@gbronline.com...
> Thanks for responding Tony:
>
> Trying to improve my memory usage and got thinking out how the compiler
> handles
> things. Never designed or wrote a compiler so in dark here.
>
> I'll address modules first -- forget about anything local to a procedure
as
> not of concern.
>
> Modules can contain Public and Private variables, subs and functions. All
> publics
> should be part of the heap while all privates should be on the module
stack.
> If both persist until the EXE unloads, then there is no difference whether
> they are
> contained on the heap or the module stack --- just different memory
> addresses.
> From an efficiency point I would think the compiler would want to release
> any
> Privates so it can free up memory when needed, and maybe would use some
form
> of table to keep the name of any Privates (variables, subs and functions)
> which would
> be dynamically reloaded as needed.
>
> If this is not the case, and you are correct that all "Module data
persists
> until the EXE/DLL is unloaded"
> then trying to group functions within modules is redundant other than to
> assist the programmer
> for mental recall -- that is you might as well have just one large module.
>
> PS> I recognize a DLL is dynamically loaded/unloaded.
>
> -------------
> Re Classes -- the same, argument for the most part, also holds true -- you
> would think that the compiler would want to dynamically release anything
> private to free up memory if not needed. I recognize that the class can
be
> terminated by the programmer which frees both heap and stack memory used
by
> the class.
>
> Thanks
> David
>
>
> "Tony Proctor" <tony_proctor@aimtechnology_NoMoreSPAM_.com> wrote in
message
> news:uishsCfiEHA.2448@TK2MSFTNGP12.phx.gbl...
> > I'm a little confused by your terms here David. Public items in a
Module
> > behave differently to Public members in a Class. The scope of Public
> Module
> > items is only within the current project (i.e. not available to the
> outside
> > world). The scope of Public members of a class depend on whether it's a
> > Public or Private class.
> >
> > If you're talking about the actual data, as opposed to the item/member
> > names, then Module data persists until the EXE/DLL is unloaded, whereas
> > class data only persists until the relevant class instance is destroyed.
> >
> > What are you trying to determine or achieve?
> >
> > Tony Proctor
> >
> > "dw85745" <dw85745@gbronline.com> wrote in message
> > news:QqadnTHZzruO37fcRVn-qw@gbronline.com...
> > > Does anyone know how the compiler handles scope in regard to Modules
and
> > > Classes?
> > >
> > > For example:
> > >
> > > If you have module or class that has Public variables, Public
> structures,
> > > and Public Functions as well as a number of Private variables,
> structures
> > > and functions, does the entire module remain open (i.e. Publics on
heap,
> > > Privates on separate module stack) while the application is loaded OR
is
> > the
> > > compiler smart enough to unload the privates, and possibly publics,
and
> if
> > > so when?
> > >
> > > Stated another way, if there is one public in a module/class does the
> > entire
> > > module/class remain in memory (both heap and module stack) throughout
> the
> > > entire application?
> > >
> > > Thanks
> > > David
> > >
> > >
> > >
> >
> >
>
>

Relevant Pages

  • Re: Exporting Symbols From C++ Object File
    ... > OR may simply change the header file from private to public and would ... The public/private stuff is not represented in the binary file because it ... The client compiler will know ... which is private and which is public from the header file. ...
    (comp.lang.cpp)
  • Re: WWDC -- MacBook Pro?
    ... ....but once the program has loaded it into its program memory, ... boundaries, int16 are aligned on 2 byte boundaries, int32 are ... people are always able to come up with the compiler ... Case B, same glass, same ice code water.  ...
    (comp.sys.mac.system)
  • Re: Javas performance far better that optimized C++
    ... The compiler is extremely stupid. ... no memory leaks are guaranteed. ... However I have GC in my .NET programming. ... "C.9.1 Automatic Garbage Collection ...
    (comp.lang.cpp)
  • Re: WaitForSingleObject() will not deadlock
    ... Whatever memory values a thread can see when it creates a new thread can ... that later locks the same mutex. ... standardized multithreading library designed to run efficiently on existing ... A C compiler is not required to do this, and it can still be a conforming C ...
    (microsoft.public.vc.mfc)
  • Re: Delphi for XCode?
    ... memory, and that it moves blocks when they are promoted to the next generation, ... Of course you can have the compiler execute e.g. an array of events. ... But what does COM have to do with MY interfaces? ... Mono is using Boehm as well. ...
    (borland.public.delphi.non-technical)