Re: Compiler and How It Handles Scope

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

Date: Thu, 26 Aug 2004 15:47:46 +0100

Can't think of any single book David. Most of this comes from previous
experience with compilers and O/S (not always under Windows)

Someone else recommended a COM book in these VB newsgroups a few days ago,
but I can't see the reference now. I believe it was "Programming Distributed
Applications with COM and Microsoft Visual Basic 6.0". It probably gets the
prize for the longest title ever, but it gives an excellent background to
COM and VB's relationship to it. I've read this one myself so I know it's
good. It may be out-of-print though.

Regarding your question about variable names: using the same name won't help
at all, and will merely obscure your code. The amount of data that a
compiler allocates space for is unrelated to the name, or whether that name
is used elsewhere. The memory associated with Module variables is accessed
only by address (or offset really). The original variable name is discarded
after the initial compilation process (unless you've asked debug symbol
table to be exported). The same is true of private classes and their
members. Public classes are a little different as symbolic information has
to be exported so that other modules can bind to them.

This is all academically interesting, but is memory usage really a problem
for you? It would have to be a truly enormous VB project for the VB
variables themselves to consume too much memory. Maybe a few more details of
why you expect there to be a resource problem.

            Tony Proctor

"dw85745" <dw85745@gbronline.com> wrote in message
news:R-mdnetdj63PfLDcRVn-tQ@gbronline.com...
> Excellent Response Mr. Proctor. Learned something. Any suggestions on a
> good book
> that might address this more. Have several VB and C++ books, but this
area
> seems
> to get little attention at best especially how to approach best from
> programming.
> I appears to be a lot of misinformation on what's going on. As I recall,
> when I took assembly,
> we just focused on moving code/data in and out of registers,
>
> Another question which relates to this is whether it makes any difference
to
> use the same
> variable name where possible throughout since as you pointed out:
>
> -------------
> All variables, whether Private or Public, are allocated relative addresses
> in that aggregate data area.
> -------------
>
> By using the same variable name, I could see where you could again have a
> table which defined just variables name with an offset for all the values
of
> that variable, in lieu of tying up memory with a different name and value.
>
> David
>
> **************************
>
> Also wanted to thank Mr. French for his input.
>
>
>
> --------------------------
> "Tony Proctor" <tony_proctor@aimtechnology_NoMoreSPAM_.com> wrote in
message
> news:uFtCww0iEHA.2808@TK2MSFTNGP10.phx.gbl...
> > 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: 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)
  • Re: If you were inventing CoBOL...
    ... > size of shared memory is the size of procedural code. ... SECTIONs and the SEGMENT-LIMIT clause as *guidelines* in that process. ... discussing what COBOL *ought to do* and what features COBOL *ought to ... Two passes in the compiler front-end. ...
    (comp.lang.cobol)