Quadword relocations - what are they?

[John McL]

To Hoff,

Today I'll write a test harness and run various options.
- access the shareable image with LIB$FIND_IMAGE_SYMBOL (which is often used here)
- linked shareable image (i.e. normal run-time library)
- move called routine into an object library and link against that (although in practice other shareable images would probably be called as well).

I'll report back here with the findings.

[John McL]

As Harmut mentioned and John Gillings mentioned earlier ... and I forgot to note in the above msg ... I'll also try to get access to experiment with /RESIDENT and /SHARED=ADDRESS. Setting up this test might not be so easy.

And these tests should keep Bob G happy too :-)

[John McL]

I'm still running tests but here's some initial data.

I'm activating a main program which then accesses a shareable image with a variable number of functions (and hence a variable number of quadword relocations) ...

For 5000 image activations

QR's = 7002 time = 57 seconds
QR's = 150894 time = 109 seconds
QR's = 712279 time = 329 seconds

In this case the shareable image was not installed but both it and the main image would have been cached.

I'm starting to think that I need to look for a balance between functions in run-time libraries and linking QR-heavy functions directly into the programs that use them (i.e. don't hurt every image that accesses the RTL but doesn't use those QR-heavy functions).

I should have more information in about 18 hours.

[John Gillings]

John,

> look for a balance between functions in
>run-time libraries and linking QR-heavy
>functions directly into the programs that
>use them

That's a bit of a rod for your own back. If you change a routine, you need to locate all references and relink them. Then you've got all the potential nasties associated with mismatched code incompatibilities.

Depending on how the routines are used, you may be able to reduce the run time impact by activating images only when actually needed. One way to do this automatically would be to create a "lightweight" shareable image that effectively only defines the entry points. This should improve your activation time to the first executable statement.

When the a routine is first called it activates the real image (using LIB$FIND_IMAGE_SYMBOL) and revectors calls through. My FAKE_RTL.COM (See OpenVMS Technical Journal) is a mechanism that will produce the lightweight shareable image automatically (though you may want to cut out the argument tracing code). Overall you're using more resources (potentially doubling the actual number of shareable images) and do more work because each call gets turned into two, but you may find it's subjectively faster because the cost of activating a particular image is only incurred when and if it's required.

[John Gillings]

Just occurred to me...

> (i.e. don't hurt every image that
>accesses the RTL but doesn't use those QR-
>heavy functions).

Another use for the FAKE_RTL technique here would be to gather statistics on actual use of different routines. You might be able to use that information to redistribute routines across different shareable images to give a better balance.

Isolate the expensive, rarely used ones in their own shareable image, possibly to be activated on demand. Put the cheap freqently used ones in a different image to be activated directly.

Your best weapon in improving performance is good quality data.

[John McL]

John G,

What you suggest is basically what we currently do. I'm in your part of the world so maybe you know this company :-)

I've only recently come on board and this investigation of image activation was the first task assigned to me.

I need to gather more data, both static about what calls what and performance related. I'm starting to think that any performance problems lie elsewhere. One thing that just may be relevant ... what's the size of the KFE hash table under v8.3? I have the (ahem) VMS 5.2 Internals book and it says 128. I'm sure it's higher now but could this be an issue? The tests I ran yesterday (see above) used LIB$FIND_IMAGE_SYMBOL but not on a KFE.

[John Gillings]

Oh, you're *that* John McL :-) Hi there! It's been a while.

I don't think the size of KFE structures is relevant to your problem, but if you really want to know, see:

$ LIB/LIST/ONLY=$KF* SYS$SHARE:LIB/MAC

Extract the ones you're interested in.

Most of the KF* symbols are in SYSDEF, so

$ ANALYZE/SYSTEM
SDA> READ SYSDEF
SDA> SHOW SYMBOL/ALL KF

will also display them. To see the structure, choose a random readable address (SHOW STACK will give you one), then

SDA> FORMAT/TYPE=KFE

SDA> FORMAT/TYPE=KFRH

Obviously the contents will be garbage, but you can see the layout of the structure. Once you've got that figured out, locate the real structures and format them.

This might be an interesting intellectual exercise, but I can't see how you can use it to speed up activations.

[John McL]

Hi John,

I asked the question beacuse I was interested in whether the amount of processing relating to working with installed images might be problem when the number of such images was large.

We are working with LIB$FIND_IMAGE_SYMBOL so there seems no necessity to install shareable images that are rarely used. In fact moving the code for the functions that are the big "quadword relocation" culprits into their own individual images might be the way to go because this means that any overhead applies only when specifically required - a kind of 'user pays' mentality.

It's also going to be a question of how the simple tests described above translate into operation on our production system. It is a question of what images we are activating and how often.

By the way, I installed the test shareable and another (that called LIB$FIND_IMAGE_SYMBOL) with /OPEN /HEADER /SHARED=ADDRESS but not /RESIDENT and the time for 1000 cycles blew out to 80 seconds compared to 63 for just /OPEN /HEADER /SHARED.

[John McL]

I've been side-tracked developing faster methods of locating the image containing a specific module but I'll be back to dealing with image activation shortly.

One question though ... Wouldn't activations be faster if we could specify a base address for the images?

This would be a "hint" to the image activator and would mean that many of the quadword relocations could be resolved with "default" values that would, if the base address couldn't be used, be re-resolved.

I believe that a base address could be specified on Vaxes but can it on Alpha and if not, why not?

[x2084]

> One question though ... Wouldn't activations
> be faster if we could specify a base
> address for the images?
>
> This would be a "hint" to the image
> activator and would mean that many of the
> quadword relocations could be resolved with
> "default" values that would, if the base
> address couldn't be used, be re-resolved.

As said before, on I64 and Alpha you can not
specify a base address for shareable images
at link time (which really are based linker
clusters on VAX, but that doesn't matter,
here). Conflicting VAs at activation time
are the main reasons for this change. But
that's not exactly what you propose, you
propose only "hints", something like a weak
base.

To make this work, you also need to link the
image for the target page size, which is at
the moment 8KB on I64 and Alpha. Ususally
shareable images are compressed at
activation time. If the linker assigns
%x10000 to the first segment (or image
section) which may contain only 200 bytes,
it assigns %x20000 for the next segment (or
image section) based on the default of
/BPAGE. At activation time, the second
segment (or image section) is mapped at an
offset of the hw page size from the first
segment (or image section). This operation
is called compressing a shareable image.
Compressing requires image relocations to be
applied.

So you suggest to create either an already
compressed shareable image, which creates a
hw dependency or an image flagged to keep it
uncompresed at activation time with address
hints where the image should be located in
the VA.

This requires a lot of work on the developer
side to get it right for multiple shareable
images, including VMS supplied ones. If one
of the images changes in size, now including
the main image, the same work may need to be
done again. You may be able to do this work
in command procedures. But you have no
control over the size of all involved
shareable images. On the other hand, if you
want to be on the safe side you are wasting
VA space.

Installing a shareable image with shared
address data is the supported alternative,
where determining the base and compressing
is done at installation time.

If I correctly understand the previous
reply, for a test you tried this and it
didn't give you the expected performance
improvement. But there you used
lib$find_image_symbol, which does more than
just activating the image: it reads the
global symbol table. So the results may not
be comparable.

To me it looks like you want to contact HP
for assistance to resolve your performance
problem.

[John McL]

Thanks Hartmut.

That was a good explanation of why a base address cannot be defined. I can rule this out as an option with improving our image activation time but I still have several other options to explore, including a more optimum mapping of modules to shareable images.

[John McL]

I had hoped to get back to this sooner but I've been busy on other issues. The question speed of image activation will probably arise again in the next few months and at least this thread has given me some useful information and ideas.

Thanks to all.