Quadword relocations - what are they?

[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.