I64 INSTALL /SHARE, process uses more private memory

[John Gillings]

>opinion that install/shared is always
>no-brainer, or not

Well, if it were a no-brainer, then all images would be automatically INSTALL/SHAREd ;-) Sorry, you'll need to evaluate the plusses and minuses.

It depends on how much sharing you expect, and how much of the image is shareable. Is the image mostly shareable code, or non-shareable data structures? What is the number of address fixups required? - remember these are per-process if the image isn't installed /SHARE=ADDRESS. Is there sufficient P1 space to use /SHARE=ADDRESS, or which images should be chosen?

If you expect enough sharing, maybe you could consider /RESIDENT? That eliminates address fixups and paging of the shareable stuff, but eats into S0/S1 space, and requires allocation of GH regions. The downside is you may require a reboot to replace a resident image, and you'll need to modify your LINK command. It's really only useful for very stable code. If the system is going to be running this image all the time anyway, why not make it resident?

(I'm not certain if /RESIDENT is applicable to executable images. If it isn't, reLINK the program as a shareable image with a single entry point "MAIN" and build a tiny jacket executable image which calls it).

[x2084]

>>>Well, if it were a no-brainer, then all images would be automatically INSTALL/SHAREd ;-) Sorry, you'll need to evaluate the plusses and >minuses.

True.

>>>What is the number of address fixups required? - remember these are per-process if the image isn't installed /SHARE=ADDRESS. Is there sufficient P1 space to use /SHARE=ADDRESS, or which images should be chosen?

I don't understand. Fixups are per image activation. If an image is installed with shared address data, the fixups are pre-applied. If the image is not activated, the process doesn't use the P1 space. It is just reserved VA space, which you can't use for any other purpose.

But that installed image is only activated, if all the images it depends on are still installed with shared address data (You can not install an image with shared address data if these other images are not installed with shared address data, but you can deinstall these other images afterwords or let logicals point to [newer] versions of these images)

You can install main images with shared address data, they do not use any P1 space, see VMSIMAGES.DAT.

>>>If you expect enough sharing, maybe you could consider /RESIDENT? That eliminates address fixups and paging of the shareable stuff, but eats into S0/S1 space, and requires allocation of GH regions.

Not true.

/RESIDENT alone does not eliminate address fixups.

Take your favorite shareable image, LIBRTL and look at the output of INSTALL LIST/GLOBAL/RESIDENT. You will see the short data segment or linkage section in P1. That's where the fixups are applied to.

LIBRTL is installed WITH shared address data, so no fixups at activation time. But if you leave out the shared addres data, its short data segment or linkage section ends up somewhere in P0 and fixups are applied at activation time.

Also, keep in mind /RESIDENT defaults to /RESIDENT=CODE. So shareable data is not yet made resident.

Also, on I64 starting with 8.3 you can use S2 space for resident code.

>>>The downside is you may require a reboot to replace a resident image, and you'll need to modify your LINK command.

Not true.

By design, resident images can be replaced in a running system. You need more resident memory, if the old image is still in use. Only if you run out of resident memory, then you need to reboot. There were some problems in this area, they are fixed in the current versions Alpha and I64, or will show in the next version of VMS.

Only on Alpha you need a modified the LINK command and relink.

>>> (I'm not certain if /RESIDENT is applicable to executable images. If it isn't, reLINK the program as a shareable image with a single entry point "MAIN" and build a tiny jacket executable image which calls it).

You can install main images with /RESIDENT (I assume your "executable images" refers to images you usually run from DCL, which I here refer to as "main images").

So you don't need to relink your main image as a shareable image. Anyway, it is known, that you can run shareable images as main image. So you don't need an additional jacket.

[John Gillings]

Hartmut,

Thanks for the corrections. Sounds like some of the limitations have been fixed. Does this mean ACTRL patches won't require a reboot any more?

[x2084]

I don't think that an ACRTL patch contains any system image. So I don't see a need for a reboot.

To replace the CRTL, aka DECC$SHR (or what the logical points to), a INSTALL REPLACE is sufficient. In case that the CRTL is in use and that there is not enough resident memory, the image is automatically installed without the /RESIDENT. That means there is a KFE for the new image and all the subsequent image activations for the DECC$SHR will use the new image.

[Lester Dreckow]

John, Hartmut,

Thanks for your interesting comments; helped my understanding of these install options.

Cheers.

[Lester Dreckow]

The SDA commands provided by John helped to explore image mapping to process pages.