From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 27-NOV-1990 10:27:46.28 To: MRGATE::"ARISIA::EVERHART" CC: Subj: re: Shareable images; how to get demand zero pages? Received: by crdgw1.ge.com (5.57/GE 1.79) id AA16047; Tue, 27 Nov 90 09:45:14 EST Received: From VENUS.YCC.YALE.EDU by CRVAX.SRI.COM with TCP; Tue, 27 NOV 90 06:03:53 PST Received: from BULLDOG.CS.YALE.EDU by Venus.YCC.Yale.Edu; Tue, 27 Nov 90 09:00 EST Received: from lrw.UUCP by BULLDOG.CS.YALE.EDU via UUCP; Tue, 27 Nov 90 08:55:58 EST Received: by lrw.UUCP (DECUS UUCP w/Smail); Tue, 27 Nov 90 08:39:03 EDT Date: Tue, 27 Nov 90 08:39:03 EDT From: Jerry Leichter Subject: re: Shareable images; how to get demand zero pages? To: INFO-VAX@KL.SRI.COM Message-Id: <9011271355.AA27752@BULLDOG.CS.YALE.EDU> X-Envelope-To: info-vax@kl.sri.COM I tried RTFM (linker manual that is) without success. We have a large library of fortran routines which access a very large common block of about 10,000 pages. For a normal link these are all demand zero pages and don't show up in the .EXE file. We have been trying to create the library as a sharable image. The linker refuses to make these pages demand-zero pages, even though we declare the psects to be /NOSHR with an options file. How can we do this?? Every image should have its own independent version of the common so there is no reason for them not to be demand zero pages. The basic answer is, you can't. This is a long-standing limitation (well, bug if you like) in the Linker/image activator/pager. For SHR pages, it's easy to see where the difficulty lies: A demand-zero page is necessarily writeable, and has to be paged to SOMETHING. Normally, pages in a shared section are paged to corresponding blocks in the shareable image file. However, the whole point of a demand-zero page is NOT to have any corresponding block in the file. Further, since shared writeable pages are supposed to end up written back, in modified form, to the shareable image, there would be no way to provide the proper semantics for such a page. NOSHR demand-zero pages don't run into the same problem, but you can see that they still require SOME kind of special handling, since normally once a demand-zero page is touched, it is replaced by a real, zeroed page; here, it would have to stay demand-zero in the global copy while the process that touched the page would have to get a real zero page, backed by the pagefile. Non-basic answer: In fact, the code to handle this IS in VMS. To allow the Linker to create demand-zero pages in a shareable image, add the option UNSUPPORTED=1 to your options file. WARNING: It's called UNSUPPORTED for a good reason! It doesn't always work right. I can't tell you what conditions actually trigger problems, nor can I even tell you what symptoms to expect if you run into some of the problems in the implementation. This hook has been in the Linker for quite some time. It's used in building some of the standard system shareable images - a quick check of the BASRTL on a V5.2-1 system reveals that images section 2 is marked DZRO, for example. The maintainers of those images get to find out from the maintainers of the relevent VMS code what works and what doesn't. You'd have to try it and hope for the best. Question number 2. Is there anyway to make a common block in a sharable image so that it could be resized. For instance if it could be placed at the very end of of the sharable image's memory and then the image linked to it could set aside additional pages to make it bigger? I'm not quite sure what this question is supposed to mean. It really has nothing to do with VMS - FORTRAN semantics provide no way to specify a common block of variable length. If you could get around that, then it's still not meaningfull for a shareable image to appear to have a different size to dif- ferent processes that use it - they are all seeing the SAME shareable image. However, if you forget about FORTRAN common blocks and think about things more generally, there is a simple, supported solution to both of your problems. Rather than trying to allocate everything at compilation time, allocate it at run time. FORTRAN is quite capable of calling either LIB$GET_VM or even the $CRMPSC system service. I'm not familiar enough with FORTRAN techniques for easily accessing the resulting memory; in something like C, you'd normally define a struct specifying the layout of the allocated memory, set a pointer to such a struct to a the address of the allocated memory, and access the mem- bers of the struct. Since VAX FORTRAN lets you define "struct"'s (records, in FORTRAN), the same technique should be workable - it's just that there may be other, more convenient approaches. By the way, one advantage of this approach is that you can create a section that maps to a file, rather than to the pagefile. This may allow you to get away with much smaller pagefiles while still allowing the code to run, even with HUGE sections. -- Jerry