Jump Development Banner

RC Icon

RAM Charger 8 For Macintosh
Home | Search | Support | Contact | Download | Order


Should I use Virtual Memory (VM) -- and File Mapping?


(Tech0007A -- 03/17/98)

Yes if you are on a PowerMac.

Otherwise, only if you need it.

Though RAM Charger "dynamic" memory is valauble no matter how much memory you have, the recent drop in RAM prices makes it very rare that users need to use virtual memory. As one RAM Charger user user wrote on our public beta list:

"Nowadays, the *need* for [increasing memory with virtual memory techniques] is greatly reduced. Ram is cheap! Dynamic allocation of memory is what is needed..." - Charles Bouldin

So, why would anyone want to use Apple Virtual Memory or RAM Doubler virtual memory?

Our opinion is that if you run any native applications you should run with virtual memory on to take advantage of File Mapping - with the LEAST amount of virtual memory you can specify. Since File Mapping is not functional under non-PowerMac systems, 68K users need not run VM unless they cannot run the programs they require with VM disabled. Because RAM Charger helps users distribute their memory more efficiently, with VM on or off, users may find that they can accomplish their objectives without enabling VM.

What is File Mapping?

File Mapping is an aspect of virtual memory wherein an application's code does not have to be loaded from your hard disk into RAM until it is required. Virutal memory must be enabled for File Mapping to be active, and connot be disabled when virtual memory is on, though no specific amount of virtual memory is required.

Using the File Mapping aspect of VM, Mac OS pretends that the entire applicaiton is in memory at application startup - by "mapping the file into memory". Then, when parts of the application are required to perform opertations (from drawing windows to spell checking to saving files) they are loaded from the disk as needed using traditional VM interupt techniques. Should RAM become full, the parts of the program not in use may be discarded - and must only be loaded again from the hard disk if it is used again.

Traditional Mac applications accomplish similar objectives using "segmenting", where the author breaks up the application into chunks which can be loaded and unloaded when required. However, the older technique requires special programming of the application, and limits the "chunks" to predefined sizes (which usually end up being relatively large). File Mapping is completely transparent to programs, requiring only that they have a "Code Fragment" in their "data fork" which is the common way Native applications are built, and load/unload will be done in relatively small "page" sizes.

Why use virtual under Power Mac?

As far as we know, File Mapping is only supported under Power Mac, and only when VM is enabled.

If you do not enable VM (and thus File Mapping) then the ENTIRE code of a NATIVE application will be loaded into RAM (because it is not segmented) when you start up the application - taking more time and RAM. If you are using Virtual Memory then Mac OS will only load the parts of the CODE into RAM that are actually being used (when they are needed). Obviously, VM's File Mapping may result in much more efficient use of your RAM and may speed up operation. If you are not running any native applications then there is no benefit to using Virtual Memory (unless you really need it).

Since Ram Doubler is an improved form of virtual memory, we recommend considering it. However, we cannot say how much better it is than the current PowerMac implementations, which may be very good, and thus what its financial "value" is.

Why the least amount of VM possible?

Use the least amount of VM possible to avoid inadvertantly using more memory than your physical RAM, which can cause slowdowns. This is especially the case when using RAM Charger since you will be able to pack the memory much more efficiently, stressing the VM system. Though using RAM Charger with VM will provide more flexibility, just like File Mapping adds more flexibility to standard VM, it will also make it easier to fill the VM and stress the system.

Since you must enable VM in order to activate File Mapping, and since filling more VM than you have real RAM can cause slowdown, and since File Mapping actually fills VM beyond the size of VM you set, we recommend setting the VM amount as low as required for your usage.

However, if you are not limited by disk space usage, and you keep in mind the possible impact from actively "using" too much of your vitual memory, there is no reason you cannot set VM as high as you like - giving you the most operational freedom. Just don't forget that this is the reason should you stress your memory and experience strange pauses and jerky operation. That is...don't blame it on me!

Why the special File Mapping name, isn't this just standard VM?

File mapping is simply an optimized aspect of VM. By tracking the "File Mapped" virtual memory code seperately, the VM system is able to recognize that when mapped code must be "paged out" (to make room in RAM for other data) it can be discarded, since it is already on the hard disk, instead of being slowly written to disk. Thus the "File Mapped" designation on some of your virtual memory speeds up operation. Giving it a cool name adds a nice buzz word for the industry. In other operating systems File Mapping is just considered part of the VM system, without any such fancy designation (as far as I know).

How much of my specific application is "File Mapped"?

If you do a "Get Info" on an application that has any "File Mappable" code, then the size of the "File Mappable" code is shown at the bottom of the Get Info window (it will say "Note: memory requirements will increase/decrease..."). This "adjustment" simply shows the size of the File Mappable code "fragment", which is stored in the data fork of the file. As far as we know, the system does not have the ability to File Map fragments in resources (speculation).

If you start with VM off then the "File Mapped" amount of memory (RAM since vm is off) will be required and used immediately on startup. If VM is on, then the "File Mapped" amount of code will be reserved in virtual memory beyond your total memory, but real RAM will not be used except for parts of the File Mapped code as they are actually used.

How much RAM is in use (the secret)?

(Or... how close am I to slowing down since RAM is full and VM will have to work hard now?)

Of special note is that the File Mapped CODE will be loaded OUTSIDE your traditional Total Memory space shown in about this mac, and thus you have no control over how much VM is allotted for CODE.

The bottom line is that if you are running native applications under Power Macintosh with VM enabled, native application CODE will be "mapped" OUTSIDE the virtual memory shown as Total Memory in your about this macintosh. As a result, be aware that if you are using Virtual Memory under Power Mac you may in fact be using WAY more virtual memory (because the native application code that has been used is mapped OUTSIDE the traditional memory space) and so you may see serious slow down.

For example:

About This Mac may show you are only using 12 of 17 megs VM on a 16 megs RAM machine, with Vm turned its lowest. However if you are running Excel you will have 10 megs file mapped (for a 27 megs total VM in reality) which may have 4 megs loaded in RAM because of the parts of the Excel applicaiton you have used were (for a total of 16 megs in use). In this case, your RAM is full despite the "12 megs" shown to be in use in About This Mac. You may start to see slowdown.

This is only important in understanding why your mac may appear to slow down apparently prematurely when using virtual memory.

So, then, how do you know how much Virtual Memory you are actually have at any given time? You would have to add up all the File Mapped code sizes listed at the bottom of the Get Info window for each running application, and add this to your total memory.

So, then, how do you know how much RAM you are actually using at any given time, and thus how close you are to stressing VM? You would have to determine how much of the File Mapped code is actually in RAM (which you can't) and add this to the memory shown to be in use. Thus, you can't figure it out. Good luck. Just don't push too hard and you may not slow down.


See Also

Home | Search | Support | Contact | Download | Order
Translate to: Français | Deutsch | Italiano | Português | Español

Please direct corrections and comment to RAMCharger (at) RAMCharger.com

Copyright © 1995-98 Jump Development Group, Inc. All rights reserved. Jump, OptiMem, RAM Charger, and More About This Mac are trademarks of Jump Development Group, Inc. Apple and Macintosh are registered trademarks of Apple Computer, Inc. All other trademarks are the property of their respective holders.