#WP & Memory
9 messages in this thread
Lynn, I've found that WP, when exited, doesn't de-allocate all its
memory. I find a loss of around 100K. While doing a "stack 5000000" command
from the CLI does recover some, most of the memory is still lost.
— Ethan
Ethan, there's a utility called Sweep around somewhere that *I believe* is
supposed to free up memory not de-allocated upon exit from programs. Haven't
tried it, just read the docs somewheres. sw
Ethan,
It's probably loading some libraries and even thou the libraries are
probably closed…they won't free up the memory they're using until the system
needs that address space.
That's a guess as to what is probably going on…your attempting a
large stack command, it it returning some memory indicates that's at least
partialy true.
Don
Do you mean that if the memory is every needed, the system will
automatically free it up, even though it is described as allocated?
— Ethan
Ethan,
Yes..in a complex fashion. Let's say the system has 4 meg of real RAM
in it. I ask for 3 Meg of workspace and get it. Joe User is also working and
also asks for 3 Meg of workspace. Well, 3 + 3 =6 which last time I looked was
larger than 4 meg.
So what the system does is take a piece of my "memory" and write it out
to disk…makes an exact image. The memory is cleared and Joe User now can use
it. When my turn comes around again…Joes' memory is written out to disk and
my memory image is written from disk back into real RAM.
Now…modern operating systems try not to do that read-write cycle on
the entire block of memory…as you can see, writing 3 meg out to disk each
time the processes swap (and reading it back in) can take quite a bit of time
even with fast drives. So what occurs is that only that portion that's needed
right that instant is moved. If I go for 30 minutes and never access that 3 Meg
of memory I requested…nothing will get moved onto/offof the hard drive.
That's a very quick and simple explanation of what's going on. It's
really alot more complex than that, because it is very likely that when I move
a piece of memory onto a disk…and then read it back…it's not going to go
back in the exact same address space it was in before. That's where the MMU
comes in…it does the equivalent of re-addressing that new space so that when
the processor attempts to access the old address, it really reads the new
address. Kind of like the mailman looking for a change of address card before
delivering mail to your home. If you've moved, your mail goes to your new
address rather than your old address…all without the the person who put the
address on the mail (the sender) having to do anything.
Make sense?
Don
Don, I think we've gotten our messages mixed up a second time. I was
asking about the memory that got left used after I exited WP, and I wanted to
know if it would be released if another program asked for the memory. Sorry
about that!
— Ethan
I've never noticed a problem. Are you taking into account wp.library? It is
normally still resident for a while after wp exits (until the memory is needed
by something else). Try flushlibs from the Workbench debug menu (i.e., 'loadwb
-debug', then select flushlibs from the extra menu).
I don't know what took up the memory, but its nothing too terrible
because a huge stack command removed 75% of it.
— Ethan
Ethan,
WP uses libraries to do it overlays. What this means is that the spell
checker (for example) is not part of the main WP program, but rather that it is
loaded when the user needs it. Because this code is in the form of a library
(a system supported method for sharing and loading extra code) it remains in
memory when WP exits. One very important feature of libraries is that they
stay in memory until the OS decides the memory for something else (and no one
is using the library). This has the benefit of being able to keep all the
extra code in memory for later use, and IF something else needs the memory the
OS can easily reclaim it. It does have the negative side of effect of people
thinking that the memory is lost.
Doing a "stack 5000000" should have released all that memory (assuming stack
doesn't have some sort of upper limit). However there is a bug in one of the
overlays which makes it think that it's still in use even when it isn't. This
occurs when you use headers, footers, footnotes or endnotes. This has been
fixed for the next update. This particular can cause a one-time loss of about
21K.
There is one other system related memory problem which we have discovered
related to the layers (CBM has admitted to this one). This particular problem
will eventually be fixed. It doesn't lose memory permanently, but it is
annoying. It can effect anywhere from 28 bytes to lots of memory (usually in
the lower range). Moving windows around to different places on the screen can
free some or all of it.
//
\X/ Lynn