|
HP OpenVMS Systemsask the wizard |
|
The Question is: Dear Wizard, How do I know when a page of memory has been loaded and is accessible ? I am processing large numbers of records using threading architecture, and therefore need access to over 1Gb of memory. I have a 512Mb guaranteed working set, with a 1.5Gb quota of un-guaranteed memory. While looping through this 1Gb of ( non-contiguous ) memory, my application causes an ACCVIO and crashes. This seems to happen around the 537Mb mark, and seems to be caused by a thread trying to access memory that has not been paged back into the 512Mb y et. If I put in printf's around this 537Mb mark, ( in effect slowing the app down considerably ), I have no problem. How can I tell when VMS has finished paging in memory, and that the memory is now reliable ? - Nathan Rozentals, Cape Town, South Africa The Answer is :
Please review the common programming errors discussion back
in topic (1661), and please review the existing discussions
of debugging access violation (ACCVIO) error. Please also
review the introduction to debugging in topic (7552).
The paging mechansisms are not the proximate cause of this
error. (The virtual memory paging mechanisms may well alter
the timing of the completion of the virtual memory access,
but paging itself does not and cannot trigger user-mode
access violations. What triggers an access violiation is
an invalid reference -- and not a reference to a page that
is currently paged out or otherwise in transition.)
The cause of the application encountering an access violation
is not related to the size of the working set nor with how
quickly OpenVMS can load a virtual page from the cache or
from backing storage. If the page in virtual memory is
invalid and must be loaded ("faulted") in, the executing
thread is placed into a Pagefault Wait (PFW) wait state
pending the availability of the page. This page transition
("page fault") is entirely and completely transparent to
application code. This transition can (and apparently has)
revealed a latent timing or caching problem, however.
Put another way, your application code likely contains either
a memory synchronization bug -- see topics (2681), (6984) and
(7383) among others -- or it contains any of a host of other
common programming bugs -- see topic (1661) for a list of some
of the more common coding bugs.
Please familiarize yourself with the meaning of the access
violation (ACCVIO) error, and particularly with the details
of the error that are provided with the access violation
signal. See HELP/MESSAGE ACCVIO, as well as discussions here.
If you were working with kernel-mode code running at an
Interrupt Priority Level (IPL) above 2 (above IPL2), then
and only then you would need to worry about the virtual memory
paging mechanisms and transitions -- and failures to correctly
process paging in elevated-IPL kernel-mode code will produce
PGFIPLHI system bugchecks. Mechanisms to probe the access
available to the caller are available for use by such code,
such as the __PAL_PROBER builtin provided by C. But the OpenVMS
Wizard will stress that this and other related builtins and
mechanisms are not applicable here. The code involved here is
very likely the residence of one or more latent bugs.
|