Re: Overlays

[Steve Baker <sjbaker1@airmail.net>]

Francesco Orsenigo wrote:
> 
> How can I control which parts of my code are loaded in memory?

Well, if you *have* to have that control, you'd build your code into
a bunch of '.so' libraries and use dlopen/dlclose to pull them in at
runtime.

However, I'd be *very* suprised if you needed that level of control.

  1) In almost all cases, the amount of memory needed by your program
     is a minute fraction of what a modern PC has.  There are very few
     programs with a million lines of source code - and even a program
     of that complexity would consume only (perhaps) 10 Megabytes of memory.
     Just one high resolution image will typically consume more RAM than the
     machine-code for your entire program!

     Hence, managing your *DATA* to avoid overflowing memory is far more
     important than managing your *CODE*.

  2) Every modern operating system (including Linux) has some kind of
     virtual memory subsystem that quietly and invisibly manages all of
     this for you.  Even if you did manage to overrun memory, Linux would
     move parts of your code and data out to the disk drive and bring them
     back in whenever they were needed again.  Your code is COMPLETELY
     unaware that this has happened - except that it would start to run
     rather slowly.

The only time you need to be really concerned about this is if your program
is running on some kind of embedded computer (like the Agenda PDA - which
runs Linux) which won't have any swap space and may have very limited amounts
of RAM.

> In other terms, when the program needs to call a function (or a global
> variable?) this function is loaded with the all the symbols (functions and
> gvars) in the entire module (in my case, the .c file?) even if i don't need
> them?

Yes - but you don't have to worry about it - that's why we have an operating
system.  You can just assume that EVERYTHING is present in memory all the time.
 
> I'm splitting my program into many of .c files, so that functions that are
> used in a particular situations are grouped, kept apart from functions that
> must be used in other situations and can be unloaded...

It's a good idea to split your program into lots of smaller files because
that makes it easier to manage and to edit...however, you only need to do
that for your own (human) benefit in making it easier to work with - once
the program is compiled, it's all smooshed together into one gigantic lump
of machine code again.

> I'm very confused about this.

The best advice is "Just don't worry about it".

> Does anybody have some clue?

Yes!  :-)

----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net>   WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net