× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Well, I'll jump in a little with what I think I understand.

All multitasking systems need to move things in and out of main memory when
different processes get to use the CPU. They use what is sometimes called
virtual memory, another name for a paging file, or a swap file in Windows,
or a swap partition in Linux, as I recall. The purpose of this is to have a
place to store things that need to be taken out of main memory, when
another task or process needs to bring something in. On my Win98 machine
it's called WIN386.SWP and is over 350meg in size.

So if MS Word is cranking away on a 100meg file,and then PhotoShop wants to
work on something that's 150meg, something's got to give. So some of what
MS Wrod was working on will be written to disk, somewhere in WIN386.SWP (or
in the swap partition in Linux - which is supposed to be created on the
fastest part of the disk).

When PhotoShop is done (or time slice expires in NT and above), then MS
Word can bring its data back into main memory.

On the 400, basically, everything (main memory, DASD) is virtual memory.
When a job needs to bring in data or program stuff, and there isn't enough
room, something has to be purged. But the system doesn't need to find
somewhere in a swap file to put it, there is already a predetermined
location - the object itself. So, one side effect of swap files does not
happen (not too much, I believe, anyway) - viz., that there can be multiple
copies of objects on disk in a Windows system (this is my supposition) -
one the real object, the other in the swap file.

I assume that, in both systems, non-data will be swapped (paged) out first.
And I am certain, because I'm working on (and trying to understand better)
some of this as I write, that when changed pages are written to disk, their
location in main memory can be marked as 'easy steal' - I guess they are
put at the end of the most-recently-used list for main memory pages.

Every object, as someone wrote, is assigned an address in the 64-bit
address space - as defined by pointers, which, although they are 16 bytes
long in CPF, actually use only 8 bytes for addressing in SLIC. But 64 bits
is a lot of addresses - just under 18.5 * 10^18, I think.

Well, enough. Probably someone will tell more of the truth. And someone
pointed at an IBM page on this stuff.

HTH

Vern

At 10:10 PM 10/28/02 -0500, you wrote:


please...  more discussion on this, more explanation.

Love the concept, love the results, haven't figured it out though.



---------------------------------------------------------
Booth Martin   http://www.MartinVT.com
Booth@MartinVT.com
---------------------------------------------------------

-------Original Message-------

From: midrange-l@midrange.com
Date: Monday, October 28, 2002 09:20:30 PM
To: midrange-l@midrange.com
Subject: Re: Paging file

Troy

A significant result of Single Level Store compared with something like
a PC Paging File is that an Object is given one set of Virtual Addresses
for
it's life(longer) when it is created.

This means that two different processes "branch" to the same address for an
object inherently. Inherent Object Code sharing.

Turn power off, Turn Power On

Same Virtual Address for the Object.

(if Object is destroyed, It's addresses are automatically
voided from any future use. (cuts down on some kinds of Viruses)

PC, Unix, Mainframe, Power Off, Power On = New set of virtual addresses.

I believe It's not a normal Paging File architecture.

John


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.