Vincent Le Chevalier wrote:

>> I mean when I monitor my system's memory usage, more memory is being 
>> used AFTER I close my program. But after several runs, the memory is 
>> returned to an earlier state.
> 
> I don't think the problem is in your program, then. When it does not run 
> anymore, it does not use memory anymore, at least on modern OSes... 
> Perhaps you could try to find a way to monitor the memory per process, 
> rather than the whole. 

No, I mean the program uses more memory when I run it, and the memory 
consumption is slightly higher after I quit than it was before I opened 
the program. It does this with other apps, too (Firefox). I don't think 
it's a problem with my program, if other programs are doing it too. 
Unless, of course, Firefox is buggy (which it might be).

Sam

Post a reply to this message

> Vincent Le Chevalier wrote:
>> Everything that wasn't new-ed.
>>
>> Normally the OS frees the memory used when the program ends anyway... 
>> So I don't understand exactly what you observe in your game. You mean 
>> it takes more memory when it runs for the 6th time than it took the 
>> first time?
> 
> I mean when I monitor my system's memory usage, more memory is being 
> used AFTER I close my program. But after several runs, the memory is 
> returned to an earlier state.
> 
> Sam
> 
Two words: disk cache.

Post a reply to this message

Memory can be free, but not available, it can
be fragmented, some other process might
have put a small amount of data in a big block,
the block is mostly empty, but is GC later by
the system after it runs out of fresh memory,
so after many levels the system packs the
memory in tighter, and the next GC takes
longer to be required because the data is
now assigned to the same blocks instead of
scattered blocks.

Post a reply to this message

"Samuel Benge" <stb### [at] THIShotmailcom> wrote in message
news:4702e940$1@news.povray.org...
> Vincent Le Chevalier wrote:

> >> I mean when I monitor my system's memory usage, more memory is being
> >> used AFTER I close my program. But after several runs, the memory is
> >> returned to an earlier state.
> >
> > I don't think the problem is in your program, then. When it does not run
> > anymore, it does not use memory anymore, at least on modern OSes...
> > Perhaps you could try to find a way to monitor the memory per process,
> > rather than the whole.
>
> No, I mean the program uses more memory when I run it, and the memory
> consumption is slightly higher after I quit than it was before I opened
> the program. It does this with other apps, too (Firefox). I don't think
> it's a problem with my program, if other programs are doing it too.
> Unless, of course, Firefox is buggy (which it might be).
>
> Sam

Your OS could be keeping the most recently used libraries in memory in case
they are going to be called again.

Post a reply to this message

Samuel Benge wrote:
> No, I mean the program uses more memory when I run it, and the memory 
> consumption is slightly higher after I quit than it was before I opened 
> the program.

I think the basic problem here is what you mean by "memory consumption". 
Memory doesn't get consumed, and all of it is always there. It's just a 
question of who happens to be using it at the moment. Once your program 
exits, your program isn't using the memory any more. There might be 
something in a cache, or the kernel may have a bug in it that's not 
marking the memory as available after your program stops using it.

But the question of "how do you know the memory is 'consumed'?" would 
likely provide clues towards answering the question of who is using it.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> But the question of "how do you know the memory is 'consumed'?" would 
> likely provide clues towards answering the question of who is using it.

  That's indeed quite relevant.

  The amount of available "free memory" is quite an irrelevant number in
any modern OS (and most of the older ones too). Even Windows. That number
doesn't really say anything. IMO it could and should be removed from the
basic user interface because it only causes confusion and serves no useful
purpose. Even some very experienced users get confused by that number.
Usually many people get worried if the amount of free memory is very low,
even though there's often absolutely nothing to it.

  Sure, the number is telling the amount of memory currently not used by
anything. However, knowing the amount of memory not used currently by
anything is basically useless information because it tells you nothing
about the state of the system. It does *not* tell how much memory will
be available for a program you will be next starting. It does *not* tell
you that the system is running out of memory and that something is wrong
because of that.

  Most OSes will use available free memory for internal things. This is
usually pretty "light" form of usage of memory in that immediately when
a new process requests more memory than is currently unused, that memory
used by the OS for its own things will be immediately freed for the process
to use.
  It may very well happen that the OS reports that there's only 1MB of free
memory in a 1GB system, yet when you start a program requiring half of a
gigabyte of memory, it runs smoothly without even the slightest bit of
swapping or anything. The OS simply stopped using part of that memory and
freed it for the process to use.

  That's why the "memory free" number doesn't really say anything.

-- 
                                                          - Warp

Post a reply to this message

Tim Attwood wrote:
> Memory can be free, but not available, it can
> be fragmented, some other process might
> have put a small amount of data in a big block,
> the block is mostly empty, but is GC later by
> the system after it runs out of fresh memory,
> so after many levels the system packs the
> memory in tighter, and the next GC takes
> longer to be required because the data is
> now assigned to the same blocks instead of
> scattered blocks.
> 

Now that makes sense!

Post a reply to this message

Ross wrote:
> Your OS could be keeping the most recently used libraries in memory in case
> they are going to be called again.

This also makes sense.

Post a reply to this message

> Darren New <dne### [at] sanrrcom> wrote:
>> But the question of "how do you know the memory is 'consumed'?" would 
>> likely provide clues towards answering the question of who is using it.
> 
>   That's indeed quite relevant.
> 
>   The amount of available "free memory" is quite an irrelevant number in
> any modern OS (and most of the older ones too). Even Windows. That number
> doesn't really say anything. IMO it could and should be removed from the
> basic user interface because it only causes confusion and serves no useful
> purpose. Even some very experienced users get confused by that number.
> Usually many people get worried if the amount of free memory is very low,
> even though there's often absolutely nothing to it.
> 
>   Sure, the number is telling the amount of memory currently not used by
> anything. However, knowing the amount of memory not used currently by
> anything is basically useless information because it tells you nothing
> about the state of the system. It does *not* tell how much memory will
> be available for a program you will be next starting. It does *not* tell
> you that the system is running out of memory and that something is wrong
> because of that.
> 
>   Most OSes will use available free memory for internal things. This is
> usually pretty "light" form of usage of memory in that immediately when
> a new process requests more memory than is currently unused, that memory
> used by the OS for its own things will be immediately freed for the process
> to use.
>   It may very well happen that the OS reports that there's only 1MB of free
> memory in a 1GB system, yet when you start a program requiring half of a
> gigabyte of memory, it runs smoothly without even the slightest bit of
> swapping or anything. The OS simply stopped using part of that memory and
> freed it for the process to use.
> 
>   That's why the "memory free" number doesn't really say anything.
> 

Free RAM is *wasted RAM*. That's why Vista has such an "aggressive" disk 
cache, pre-fetching files even before you open them.

Post a reply to this message

Warp wrote:
>   That's why the "memory free" number doesn't really say anything.

Interestingly...

The Amiga OS, when unable to satisfy a request to allocate RAM(*), would 
loop through all the loaded libraries and invoke in each the standard 
entry point intended to unload the library from RAM, then try again. If 
someone still had the library open, the library would refuse to free() 
its memory of course. If the library was closed, it was supposed to call 
free() on any memory it had allocated, and then free itself (via some 
mechanism I don't recall 20 years later offhand).

There was one library that would cache stuff for you (disk pages, if I 
recall), and when the "unload" entry was called, would free the memory 
in the cache without actually exiting.  Another one let you register 
with that library, and when *it* got the unload call, it would pass it 
on to everyone who had registered, so you could (say) trim the undo 
stack down some rather than crash some other program.

Overall, a pretty cool functionality for such a simple mechanism. It's 
amazing how flexible AmigaOS was, simply by having a handful of 
primitives that it *didn't* try to combine for you into what the 
designers thought you'd want to do.


(*) In the good old days, back before desktop CPUs handled page faults...

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message