Article 169964 of comp.os.vms: In article <5li9rc$km8@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu writes: > In article , jtb@ikp.atm.com.pl (Jacek W. Tobiasz) writes: > >>For Unix (and Irix :-) look at man dlsym,dlopen,dlerror. Don't know if it >>is standard (in unix sense :-) but it work with Irix and Solaris. >>You Know the answer for VMS from other posts. > > Thanks, exactly what I was looking for. > > I see that there is also a dlclose(), but apparently nothing similar for > OpenVMS. > > The description for lib$find_image_symbol says: > > The Find Universal Symbol in Shareable Image File routine reads > universal symbols from the shareable image file. This routine > then dynamically activates a shareable image into the P0 address > space of a process. > > Fine, but how does one then later remove this shareable image? Admittedly, > if you have only one or two "plug in" libraries, it shouldn't be a problem, > but what if you have 30 or 40? Won't these at some point use up the > process's available memory? Since it says the whole shareable goes up into > P0 space the only thing you could do to use up less memory would be to make > many smaller shareables, so that only the one function of interest loaded. > Or am I misreading this, and it only loads functions into physical memory > from the shareable as needed, rather than the whole thing at once. (In Irix > dlopen() parlance, is VMS doing RTLD_LAZY or RTLD_NOW?) VMS never loads *anything* into physical memory unless it is actually used. (Well, that's not *completely* true, but for this discussion we will disregard loadable images and nonpaged pool and concentrate on user mode stuff.) It's inherent in the nature of a Virtual Memory System, which of course is what VMS stands for. :-) When an image is activated, whether it is a main image or a shareable image, it is not *loaded*, it is *mapped*. This means that a virtual address range is assigned to it and page table entries are created, so that it *can* be loaded into physical memory as needed. However, none of the pages of the image are so loaded at activation time. When the program starts execution, the entry point is called by the image startup routine. This causes a page fault, since the entry point page is mapped, but not in physical memory. The backing store of a readonly page is the image file, so the pager will go there to get the contents of the page. After the page is loaded from the image file (page fault cluster really, since manipulating single pages is inefficient), it is marked valid and the instruction which got the page fault is restarted. Note that the entire image is not loaded into physical memory at this point, just a single page fault cluster. As the program continues execution, more page faults occur. Gradually the active parts of the program are brought into physical memory. Code paths that are heavily used tend to remain in memory, while paths that are less heavily used, especially initialization code that is executed only once, get paged out of physical memory. The initialization code code never returns to physical memory, while some paths may come back. The pager makes no distinction between code and data. The data areas are paged in and out based on usage the same as the code. The hot data structures remain in physical memory and those that are less active get paged out. The pages of a shareable image, whether statically or dynamically mapped to the process, are treated exactly the same as the main image as far as paging is concerned, unless the shareable image is installed shared. In this case, the pages of the shareable image may be mapped by many processes at the same time, i.e. they are sharing the same physical pages. When one process faults a shared page into physical memory, the other processes will be able to use the page immediately without a page fault. You were concerned about the shareable images accumulating in P0 space. Are you aware that image rundown, which occurs when a main image exits, makes them all go away? In fact, P0 space itself goes away on image rundown and part of P1 space as well. If I remember your description of what you were trying to do, you wanted to run an program, passing the name of a shareable to dynamically load on the command line. Then you ran another program with another dynamically loaded shareable. I got the impression that there was only one dynamic shareable per main image activation. If this is the case, you do not have to worry about shareable images accumulating. Every time a main program exits, all images are run down, including any shareable images it has activated, either statically or dynamically. One more point regarding shareables. You were concerned about the size of the images. As described above, this is largely irrelevant, since physical memory is consumed only by pages that are actually used. There is some cost to *mapping* a large image, but it is not great. Essentially you need a page table entry for each page that is mapped. On the VAX, this is a longword. Thus you are consuming 4 bytes for every 512 bytes that is mapped. On the Alpha, page sizes are much bigger, so there are fewer PTEs. On the other hand, I believe the Alpha PTEs are quadwords. The other point to consider with large images is quotas and limits. The total number of virtual pages for the process, including the main image, shareable images, and all dynamically allocated virtual memory such as with get_vm and malloc, must be less than the sysgen parameter virtualpagecnt. Page file quota is typically not a factor for shareable images, since readonly pages are not included in this quota. It is possible for shareable images to have writable sections however. If the writeable section is shared, then the backing store is the image file, so page file quota is not used. If it is not shared, i.e. process private, then the backing store is the page file, which takes up page file quota for the process. Since the virtual memory in windows nt is based on the vms model, much of the above may apply to nt as well. Much of the low level stuff appears to work very much like VMS. It's the higher level functions that were polluted by Bill Gates. Wayne -- =============================================================================== Wayne Sewell, Tachyon Software Consulting (214)553-9760 wayne@tachyon.xxx http://www.tachyon.xxx/www/tachyon.html and wayne.html change .xxx to .com in addresses above, assuming you are not a spambot :-) =============================================================================== C3PO(during Falcon liftoff): "I'd forgotten how much I hate space travel."