NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/vmsnet/internal/1114

Internet Message Format | 1992-07-24 | 3.3 KB

Path: sparky!uunet!wupost!cs.utexas.edu!rutgers!dziuxsolim.rutgers.edu!zodiac.rutgers.edu!leichter
From: [e-mail]
Newsgroups: vmsnet.internals
Subject: RE: VMS Memory Management/PGFLQUOTA question
Message-ID: <[e-mail]>
Date: 24 Jul 92 12:13:32 GMT
References: <51000F6F_00057EE8.0095DF402228FBE0$[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Rutgers University Computing Services
Lines: 53
Nntp-Posting-Host: cancer.rutgers.edu

In article <[e-mail]>, [e-mail] writes:
||| address space for my exclusive use in an image.  We're talking a quarter of a
||| gigabyte or so here.
|
|| Why is it desired to greate a quarter-Gbyte address space that is reserved
|| against use by system routines, but not associated with backing store? The
|| only thing I can think of is come sort of very sparsely populated matrix,
|| but there are better ways to code these as linked lists...
|
| You are basically correct.  It's not actually a matrix but it is a large
| yet extremely sparse data structure.  If you like, though, you can think
| of it as a huge matrix.  HOWEVER, I don't have control over how the matrix
| cells are accessed.  Think of me as a lowly library routine responsible only
| for creating this monstrosity.
|
| The matrix has to look to the user as if it really is all there, but my  code
| fields the access violations on non-existent pages (using a condition handler
| in the secondary vector or something), do a $CRETVA on the pages as they are
| accessed, and continue.

Well, the first thing to realize is that you can't really do what you want:
The VAX architecture doesn't support sparse page tables.  A page table always
runs contiguously from page 0 up to some page.  If you want a process to have
"a quarter of a gigabyte or so" of VM, you'll have to VIRTUALPAGECNT that
high.  That's probably beyond the supported value, and will certainly cause
quite a hit on your system, as it will cause the size of all the balance sets
to grow to cover it.  I hope you have a LOT of real memory.

Now, given that you accept this limitation, you have to look at just what you
are trying to accomplish.  You want a region of addresses (which don't yet
correspond to memory) from START to END which you know no one else will
ever use.  The only way such memory might be used is if someone allocated it,
either useing LIB$GET_VM or one of the VMS memory system services.  The
former is easy to deal with:  If LIB$GET_VM needs more memory, it always
allocates it at the end of P0, use $EXPREG.  Direct calls to $EXPREG, of
course, also allocate at the end of P0, as do most other things that allocated
VM.  (The only thing that DOESN'T is $CRETVA.  You can do absolutely nothing
about that.)

So, we simply have to ensure that we've put END at the end of P0.  This is
easy:

    Use $EXPREG to allocate one page.  Its beginning address is START.
    Calculate END from START.
    Use $CRETVA to allocate the single page containing START.  The
        addresses between START and END will not be usable by
        LIB$GET_VM, $EXPREG, and such, and will not correspond to
        any real memory or backing store until you use $CRETVA to
        allocate them.

Expect poor performance.  Neither the VAX architecture nor VMS are designed
for this kind of application.
                            -- Jerry