> 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