install> /share=ADDRESS - Any downside?

[Richard J Maher]

Hi,

I've personally never used the "= ADDRESS_DATA" option of the ADD
image/SHARE command in the INSTALL utility in anger. From what little
documentation I can find it looks like the mutt's nuts and it's all good: -

/SHARED[=[NO]ADDRESS_DATA]
/NOSHARED
Installs the file as a shared known image and creates global sections for
the image sections that can be shared. An image installed shared is
implicitly installed open.
When you use the ADDRESS_DATA keyword with the /SHARED qualifier, P1 space
addresses are assigned for shareable images. With the assigned addresses,
the Install utility can determine the content of an address data section
when the image is installed rather than when it is activated, reducing CPU
and I/O time. A global section is created to allow shared access to address
data image sections.

What, if any, is the additional overhead of using P1 addresses (normally P0
?) and allocating the memory at INSTALL-time?

I'd like to: -

$ install add sys$share:t3$private/protect/open/header/share=ADDRESS

to work around a bug in VMS/IA64 as detailed in: -
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1312923

But I'm just wondering "When would you install and image with /SHARED and
not use /SHARED=ADDRESS?". Any SYSGEN parameters (like GH_RSRVPGCNT for
/RESIDENT) or process quotas that need watching or tweaking?

Cheers Richard Maher

[John Gillings]

Richard,

Excellent question! I think the depletion of P1 space is the only significant constraint. Remember it's only 1GB (hard, permanent, architectural limit) and needs to hold quite a lot of stuff. I'd be keeping an eye on how much space my images consume.

I think there was once an issue (a leak or bug) that caused trouble when you tried to INSTALL/REPLACE a /SHARED=ADDRESS image, but I don't think it's still relevant. On the other hand, I'd be a bit concerned about very frequent /REPLACEs. INSTALL can be a bit flakey.

There's also a propagation issue. Any images on which your image depends must also be INSTALLed /SHARED=ADDRESS. IIRC, if you uninstall a lower level image, the activator will (silently) activate your image without the shared address sections. I have no idea what effect that would have on your bug! (might be interesting to experiment).

[Richard J Maher]

Hi John,

Thanks for the reply.

I did come across the dependency issue with T3$PUBLIC and T3$PRIVATE both needing the /share=ADDRESS option.

When it comes to calculating P1-specific usage or o/head what, if anything could you glean from this: -

$ install list/full sys$library:t3$private

DISK$I831H1SYS:.EXE
T3$PRIVATE;2 Open Hdr SharAddr Prot Lnkbl
Entry access count = 2
Current / Maximum shared = 0 / 0
Global section count = 8
Resident section count = 0000

$ install list/glob sys$library:t3$private

DISK$I831H1SYS:.EXE
T3$PRIVATE;2 Open Hdr SharAddr Prot Lnkbl

System Global Sections

RX2600$DKA100:T3$PRIVATE.EXE
INS$8FAC1E90_010(03000001) DZRO PRM SYS Pgltcnt/Refcnt=16/2
INS$8FAC1E90_009(03000001) DZRO PRM SYS Pgltcnt/Refcnt=16/2
INS$8FAC1E90_007(03000001) DZRO PRM SYS Pgltcnt/Refcnt=16/2
INS$8FAC1E90_005(03000001) DZRO PRM SYS Pgltcnt/Refcnt=16/2
INS$8FAC1E90_004(03000001) DZRO PRM SYS Pgltcnt/Refcnt=16/2
INS$8FAC1E90_008(03000001) PRM SYS Pgltcnt/Refcnt=11/0
INS$8FAC1E90_006(03000001) PRM SYS Pgltcnt/Refcnt=9/2
INS$8FAC1E90_003(03000001) PRM SYS Pgltcnt/Refcnt=43/6

$ install list/struct sys$library:t3$private

RX2600$DKA100:.EXE
List head adr/siz/ref = 8F684070/58/201

T3$PRIVATE;2 Open Hdr SharAddr Prot Lnkbl

One other thing that's probably worth stating is that obviously not all images are capable of taking advantage or the ADDRESS_DATA option. For example: -

$ install add sys$library:rdb$cosip.exe/open/head/protected/share=address
%INSTALL-I-NONSHRADR, DISK$I831H1SYS:RDB$COSIP.EXE installed ignoring '/SHARE=ADDRESS'
-INSTALL-E-NOT_MAPPED, target address not mapped
-INSTALL-I-ADDRINFO, %X00060000 (not mapped address, link-time value)

Cheers Richard Maher

[Ian Miller.]

Have you tried INSTALL/RESIDENT?

I think this places the image in S2 space thus avoiding the limitation on P1.

[x2084 · Accepted solution]

>>> I think there was once an issue (a leak or bug) that caused trouble when you tried to INSTALL/REPLACE a /SHARED=ADDRESS image, but I don't think it's still relevant. On the other hand, I'd be a bit concerned about very frequent /REPLACEs. INSTALL can be a bit flakey.

There shouldn't be any more such leaks in V8.3-1H1. Please note, if you replace a shareable, which is still in use, both are mapped. The new one gets a different addresse space. At image rundown the old shareable "goes away". If the referencing image(s) aren't run down, this looks like a leak

As you probably know, the SYSGEN parameter IMGREG_PAGES sets the address range used to images with shared address data.

>>> ... the activator will (silently) activate your image without the shared address sections. I have no idea what effect that would have on your bug! (might be interesting to experiment).

Then, from an image activator point of view, the shareable is not installed.

>>> When it comes to calculating P1-specific usage or o/head what, if anything could you glean from this: -
$ install list/full sys$library:t3$private
...
$ install list/glob sys$library:t3$private

For the used address space in P1, you want to use /resident (I'm sure, ITRC will nicely format the following output)

$ install list sys$disk:[]sad/res

DISK$VMSI64_XBZ7:.EXE
SAD;10 Open Hdr SharAddr Lnkbl

00000000.7C524000 00000000.7C524013 00000000.00000014 Writeable data
00000000.7C526000 00000000.7C52600F 00000000.00000010 Code
00000000.7C528000 00000000.7C528003 00000000.00000004 Read-only data
00000000.7C52A000 00000000.7C52A02F 00000000.00000030 Read-only data
00000000.7C52C000 00000000.7C52C067 00000000.00000068 Read-only short

The global sections are only part of the image address space: you miss the process private sections. And there is a global section for non-P1 address space listed: the very last segment, which contains the image activation data. In other words, it's not part of "your" image.

>>> One other thing that's probably worth stating is that obviously not all images are capable of taking advantage or the ADDRESS_DATA option. For example: -

Because the protected image has some address data in read-write image sections/segments, which can bot be shared. Install now gives a hint, where to look to change this. It looks like the PSECT at 60000 is the one.

You can think of images installed with shared address data as "based shareable images". They are based at installation time.

>>> Have you tried INSTALL/RESIDENT?

This will only move code (and shared read-only data, if you say so) into system space. All process sections stay in P0. You can combine that with SharAddr, then the process sections are in P1.

>>> I think this places the image in S2 space thus avoiding the limitation on P1.

Before V8.3 this was in S0/S1. Plain V8.3 on I64 placed that into S2. That was not a good idea. A V8.3 ECO reverted that to pre V8.3 behavior. V8.3-1H1 uses S0/S1, again. But you can configure and use S2 space. However, you must confirm at link time, that your code is 64bit ready. Otherwise it will not be moved to S2. The release notes should have some documentation on that.

[John Gillings]

Richard,

>When it comes to calculating P1-specific
>usage or o/head what, if anything could you
>glean from this: -

Initial observation - the pagelet counts are all 2 digits, so the P1 consumption is probably no more than noise. Unless you have a LOT of images, it won't be too loud ;-)

I'd compare what INSTALL LIST/FULL says with and without /SHARED=ADDRESS on the assumption that any differences are the P1 sections.

As a cross check,

For non-protected image RUN/DEBUG and SHOW IMAGE and look for P1 sections in the image map. For your protected image, use SDA from another process to see the image layout and add up the P1 sections. Again, it may be instructive to compare the same image with and without /SHARED=ADDRESS.

/RESIDENT and /SHARED=ADDRESS (is it implied with /RESIDENT? No access to HELP right now, so I can't check) in P2 space will obviously fix any virtual address constraints, but as Hartmut pointed out, you need to check your code for 64 bit compatibility. You also need to link with /SECTION_BINDING, and, as you've already noted, provide sufficient RSRVPGCNT - I usually recommend allocating at least 3x the image requirements so you can /REPLACE even if there are other processes holding the existing image. Memory's cheap, right?

[Richard J Maher]

Thanks everyone for the replies! They've been very instructive and helpful.

Regarding /RESIDENT these images have always been linked /SECTION_BINDING but I left it up to the System Manager to decide if that's what they'd want to do. (Has anyone even tested that this is an alternative "solution" to the file protection issue?)

All I'm doing here is trying to work around the bug in the image activator, discussed at length here: -
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1312923

I could: -

1) Wait for HP/VMS to come out with a fix (Given that they skip regression testing it shouldn't be long :-)
2) Lower the file protection on my images to W:RE (Like Rdb Engineering)
3) Install the two RTLs with /SHARE=ADDRESS

I chose "3" which has some nice upside and almost no downside

You'll all be glad to know that barring this issue, and a couple of floating point problems, Tier3 moved over to IA64 without a hitch - off to testing. . .

Cheers Richard Maher

PS. If you'd like to participate in a beta test let me know.

[x2084]

>>> /RESIDENT and /SHARED=ADDRESS (is it implied with /RESIDENT?...

No./resident installs only your code (on I64 that includes unwind data).

>>> /RESIDENT and /SHARED=ADDRESS...in P2 space will obviously fix any virtual address constraints...

Looks like a typo: in S2 space. You can't install into P2. You can link your image to use P2 space. That's what you need to do to declare it 64bit ready. And that's I64 only.

>>> Regarding /RESIDENT these images have always been linked /SECTION_BINDING...

Section binding is an Alpha thing. It (suppresses some Alpha specific link-time branch optimisations and) creates image relocations, which are required if you want to move the image to non-linker assigned addresses. On I64 all images contain image relocations. For compatibility the I64 linker accepts the switch, but doesn't use it.

[Richard J Maher]

Hi Hartmut,

Thanks for the clarifications and yes I had seen that /section_binding is the norm on IA64.

Anyway, as I go off to put a hardware-specific install into my t3$startup.com I'd just like to ask anyone (for curiosity's sake) why NOPRIV is the error returned here: -

%VMSINSTAL-I-MOVEFILES, Files will now be moved to their target directories...
%INSTALL-I-NONSHRADR, image installed ignoring '/SHARE=ADDRESS' DISK$ALPHASYS:T3$PUBLIC.EXE
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
%INSTALL-I-NOTSHRADR, T3$PUBLIC is not installed with shareable address data
%INSTALL-I-NONSHRADR, image installed ignoring '/SHARE=ADDRESS' DISK$ALPHASYS:T3$PRIVATE.EXE

On what version of Alpha/VMS did /share=ADDRESS become supported (I'm guessing sometime after 7.2-2)and why is it only failing when the IVP is run by VMSINSTAL?

Cheers Richard Maher

PS. NO I don't want to here *anything* about PCSI!

[x2084]

>>> Anyway, as I go off to put a hardware-specific install into my t3$startup.com I'd just like to ask anyone (for curiosity's sake) why NOPRIV is the error returned here: -

The segment/image section with the shared address data needs to be relocated - adjusted to the assigned P1 addresses. Therefore the global section is set up as DZRO and the segment/image section data is read from the image file. The process, which installs the image, needs read access to the image file. It looks like that's not the case, here.

>>> On what version of Alpha/VMS did /share=ADDRESS become supported

6.2 as far as I know.

>>> ... why is it only failing when the IVP is run by VMSINSTAL

Sorry, I don't understand the question and how that is related to the IVP.