virtual memory

I want to clear my virtual memory concept.
Is virtual memory, a part of hard disk or NAND Flash (some indirect
addressable memory).

http://en.wikipedia.org/wiki/Virtual_Memory
are you comfusing memory swap with VM?

"khan" <mushtaqk_921@yahoo.co.in> wrote in message
news:1147169261.671107.89850@i39g2000cwa.googlegroups.com...
> I want to clear my virtual memory concept.
> Is virtual memory, a part of hard disk or NAND Flash (some indirect
> addressable memory).
>

"khan" <mushtaqk_921@yahoo.co.in> wrote in message 
news:1147169261.671107.89850@i39g2000cwa.googlegroups.com...
>I want to clear my virtual memory concept.
> Is virtual memory, a part of hard disk or NAND Flash (some indirect
> addressable memory).
>

Virtual memory is frequently on a hard disc but is probably not in NAND 
flash. Virtual memory is memory that isn't really there. Say you have 16MB 
of RAM, 100MB of Hard disc and a 32MB of data you want in memory. The first 
16MB would go into RAM and then a virtual memory controller would store the 
remaining 16MB on the hard disc in an file reserved as "Virtual Memory". The 
program accessing the data will not know or care whether the memory it is 
accessing is in RAM or on the disc - it all looks the same from outside.

It is not impossible for the virtual memory area to be in a NAND flash but 
if I would tend to use something that doesn't wear out as it is written to. 

"khan" <mushtaqk_921@yahoo.co.in> wrote in message 
news:1147169261.671107.89850@i39g2000cwa.googlegroups.com...
>I want to clear my virtual memory concept.
> Is virtual memory, a part of hard disk or NAND Flash (some indirect
> addressable memory).
>
Virtual memory could be both but it is always a bad idea to use flash 
memory. You'll wear it out very fast. 
http://en.wikipedia.org/wiki/Virtual_memory

Peter 

Tom Lucas wrote:
> "khan" <mushtaqk_921@yahoo.co.in> wrote in message 
> news:1147169261.671107.89850@i39g2000cwa.googlegroups.com...
>> I want to clear my virtual memory concept.
>> Is virtual memory, a part of hard disk or NAND Flash (some indirect
>> addressable memory).
>>
> 
> Virtual memory is frequently on a hard disc but is probably not in NAND 
> flash. Virtual memory is memory that isn't really there. Say you have 16MB 
> of RAM, 100MB of Hard disc and a 32MB of data you want in memory. The first 
> 16MB would go into RAM and then a virtual memory controller would store the 
> remaining 16MB on the hard disc in an file reserved as "Virtual Memory". The 
> program accessing the data will not know or care whether the memory it is 
> accessing is in RAM or on the disc - it all looks the same from outside.
> 
> It is not impossible for the virtual memory area to be in a NAND flash but 
> if I would tend to use something that doesn't wear out as it is written to. 
> 

No, you are confusing virtual memory with swap space.  The concepts are 
related, but not identical.  In particular, you can have virtual memory 
without swap space, but not vice versa.

The terms "physical memory" and "physical addresses" refer to actual 
memory connected to the processor and directly accessible by it.  This 
is what is meant when you say a system has, say, 256 MB ram.  The 
physical address range is limited by the number of address pins (or chip 
selects, or sdram address range, or whatever).  The physical address is 
therefore the address seen by the memory hardware.

The "virtual address", on the other hand, is the address seen by 
software, which can be quite different.  There are three possible 
reasons for making it different - one is to give the software the 
illusion that it has access to more memory than the system has 
physically, another is to give the software the illusion of a single 
contiguous memory block even if the physical memory mapped to the 
virtual memory is piecewise, and the final reason is to ensure that 
separate applications have separate memory spaces.  A virtual memory 
system can implement any or all of these systems, with only the first 
requiring swap space.

On Tue, 9 May 2006 11:26:28 +0100, "Tom Lucas"
<news@REMOVEautoTOflameREPLY.clara.co.uk> wrote:

>It is not impossible for the virtual memory area to be in a NAND flash but 
>if I would tend to use something that doesn't wear out as it is written to. 

NAND flash could be used to load read-only pages (such as code)
directly into physical RAM in demand paging. If the physical RAM
becomes full and some pages must be discarded, read-only pages can be
discarded and loaded again from the original store (e.g. executable
file).

However, modified "dirty" pages needs to be saved into a secondary
store (page file) if these pages must be removed from physical RAM to
make room for other pages. The page file should not be on the Flash,
since the frequent writes to the page file would destroy it quickly.

Unfortunately some operating systems have a tendency to try to purge
pages from physical RAM just as a precaution even if the physical
memory would be much larger than the sum of all programs ever executed
in the system. Thus desktop operating systems should not moved to a
Flash only system without doing something to the page file mechanism.

Paul

David Brown wrote:
>No, you are confusing virtual memory with swap space.  The concepts are 
>related, but not identical.  In particular, you can have virtual memory 
>without swap space, but not vice versa.

This is not correct. I have worked with a RTOS on Hewlett-Packard
minicomputers that did not have any support for virtual memory, (no
MMU, no traps on accessing invalid addresses, no restartable
instructions, etc.) but did support swapping.
At "sysgen" (system configuration) time you could partition the memory
not used by the OS itself into non-overlapping regions. When linking a
program, you had to tell what region it should use.  More than one
active program could use the same region, (i.e. they were linked to
use the same physical memory,) and the OS would swap them in and out
(to disk)  as needed.
This was a standard technique before MMUs became common place, as well
as support for "Program Overlays", which we could call a poor man's
swapping mechanism. (Anybody still using overlays?)


Roberto Waltman

On Tue, 09 May 2006 10:01:06 -0400, Roberto Waltman
<usenet@rwaltman.net> wrote:

>David Brown wrote:
>>No, you are confusing virtual memory with swap space.  The concepts are 
>>related, but not identical.  In particular, you can have virtual memory 
>>without swap space, but not vice versa.
>
>This is not correct. I have worked with a RTOS on Hewlett-Packard
>minicomputers that did not have any support for virtual memory, (no
>MMU, no traps on accessing invalid addresses, no restartable
>instructions, etc.) but did support swapping.
>At "sysgen" (system configuration) time you could partition the memory
>not used by the OS itself into non-overlapping regions. When linking a
>program, you had to tell what region it should use.  More than one
>active program could use the same region, (i.e. they were linked to
>use the same physical memory,) and the OS would swap them in and out
>(to disk)  as needed.

>This was a standard technique before MMUs became common place, as well
>as support for "Program Overlays", which we could call a poor man's
>swapping mechanism. (Anybody still using overlays?)

I'll add my own experience with HP 201x processors and their
timesharing system.  It also did swapping without any virtual address
system involved.  A portion of the main CPU memory (there was an IO
processor with half the memory, as well), was reserved for the program
space and the rest for the timesharing system.  In addition, various
'commands' were also loaded into the swap space for their execution,
allowing for extending the operating system features.

Not only was their no virtual memory, there was no hardware support
for a stack.

I suspect similar things were done on PDP-8s and other computers of
that day and earlier, such as the IBM 360.

Jon

> I suspect similar things were done on PDP-8s and other computers of
> that day and earlier, such as the IBM 360.

I have done similar - to an extent - things later (mid 90-s) on a 68340
CPU. It had no MMU, but the OS - DPS, which now happily runs on
a PPC with an MMU and normal VM - did have dynamic memory
cluster allocation from day one. What I did was provide a call
(actually
a set of calls)  for the applications which would allow them to
knowingly
release (typically large) regions of memory when they did not need
them for some time so this memory could be allocated to other tasks
(being written to the swap file before that). The application which had
released a memory region could claim it back using a call and would
get it again contiguosly allocated although perhaps placed at some
other
address (obviously the code had to be written to take that into
account,
not a big issue since the actual address was returned by the call).
The PPC version actually still supports all that - same old sources -
but
only old applications use it, I have not (yet?) written new ones to use
this mechanism.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------


Jonathan Kirwan wrote:
> On Tue, 09 May 2006 10:01:06 -0400, Roberto Waltman
> <usenet@rwaltman.net> wrote:
>
> >David Brown wrote:
> >>No, you are confusing virtual memory with swap space.  The concepts are
> >>related, but not identical.  In particular, you can have virtual memory
> >>without swap space, but not vice versa.
> >
> >This is not correct. I have worked with a RTOS on Hewlett-Packard
> >minicomputers that did not have any support for virtual memory, (no
> >MMU, no traps on accessing invalid addresses, no restartable
> >instructions, etc.) but did support swapping.
> >At "sysgen" (system configuration) time you could partition the memory
> >not used by the OS itself into non-overlapping regions. When linking a
> >program, you had to tell what region it should use.  More than one
> >active program could use the same region, (i.e. they were linked to
> >use the same physical memory,) and the OS would swap them in and out
> >(to disk)  as needed.
>
> >This was a standard technique before MMUs became common place, as well
> >as support for "Program Overlays", which we could call a poor man's
> >swapping mechanism. (Anybody still using overlays?)
>
> I'll add my own experience with HP 201x processors and their
> timesharing system.  It also did swapping without any virtual address
> system involved.  A portion of the main CPU memory (there was an IO
> processor with half the memory, as well), was reserved for the program
> space and the rest for the timesharing system.  In addition, various
> 'commands' were also loaded into the swap space for their execution,
> allowing for extending the operating system features.
>
> Not only was their no virtual memory, there was no hardware support
> for a stack.
>
> I suspect similar things were done on PDP-8s and other computers of
> that day and earlier, such as the IBM 360.
> 
> Jon

David Brown wrote:


> 
> The "virtual address", on the other hand, is the address seen by 
> software, which can be quite different.  There are three possible 
> reasons for making it different - one is to give the software the 
> illusion that it has access to more memory than the system has 
> physically, another is to give the software the illusion of a single 
> contiguous memory block even if the physical memory mapped to the 
> virtual memory is piecewise, and the final reason is to ensure that 
> separate applications have separate memory spaces.  A virtual memory 
> system can implement any or all of these systems, with only the first 
> requiring swap space.
> 


When did memory management become synonymous with VM? There were memory
management units in computers since the early 1960s and except for
systems which implemented VM (eg. S/360) they did not use the
terminology "virtual address".

BTW, a well-known example of swapping without VM was implemented on
the CDC 6000 series running SCOPE or derivatives; tasks or jobs were
rolled in or out from a control point by the operator or automatically
by job control (under supervision by a PPU program).

Michael Grigoni
Cybertheque Museum