Quadword relocations - what are they?

[John McL]

I see from ANALYZE/IMAGE that the code I am working with has thousands of "quadword relocations" in the Image Activator Fixup Section.

Do these cause overheads at image activation and if so, what cauuses them and how can they be minimised?

It might help if I tell you that the code is a mixture of Cobol and C modules.

[Wim Van den Wyngaert]

http://h71000.www7.hp.com/doc/82final/5601/aa-pv64e-te.pdf

Chapter 4.

Wim

[Volker Halle]

John,

please disregard the previous answer !

You will find the description of Linker 'Longword and Quadword Address Fixups' in the OpenVMS Internals and Data Structure Manual Chapter 28.4.4:

A longword address record or quadword address record (or both) exists for each shareable image that is the target of .ADDRESS or .ASCID directives.
...

You will also find some references in the OpenVMS Linker manual.

Volker.

[Volker Halle]

John,

here is a more complete answer. Note that I'm just the messenger ;-)

Volker.

This has nothing to do with unaligned data. This has nothing to do with performance, once the image is activated.

Which platform? I conclude Alpha because the term "Image Activator Fixup Section" was used. How often is the image activated?

On Alpha you have either a shareable image or a main image linked with /section_binding. (On I64 all images have relocations.)

On I64 and on Alpha, an image is only relocated if it can not be placed at the linker suggested addresses: shareable images and main images installed /resident. In any other case none of the image relocations is applied.

If relocations are applied at image activation it takes time to do them.
This is usually faster on I64 than on Alpha, as a result on how the relocations are retrieved from the image file.

You can not avoid applying them. (You can not assign the to be used addresses in the linker: there are no based shareable images on Alpha or on I64.) But you can try to install your image with shared address data.
With shared address data it is tried to apply all the relocations at installation time. It depends on your application, if it is possible.
That is, if your image can be installed with shared address data. If there is a relocation to be applied to a section, which can not be mapped at installation time (for example a writable process section), using shared address data is turned off.

You can't do much at programming level. Image relocations are necessary if you need an address value. It might help if you can use pointers and offsets instead of always pointers.

If the image is activated only a few times, it isn't worth to do anything.

[Wim Van den Wyngaert]

A better one :
http://h71000.www7.hp.com/doc/82final/vax-to-itanium-porting.pdf

(look for e.g. quad)

Wim

[Volker Halle]

re: Wim,

this has nothing to do with unaligned data !

Please re-read my previous posting.

Volker.

[Wim Van den Wyngaert]

Please zero me. I tried and failed.

Wim

[John Reagan]

Mostly coming from your COBOL code I'll guess.

The compiler generates various data structures that the RTL uses at run-time. Many of these data structures contain addresses of your data. Things like the COBOL CANCEL statement wants to return the program to its initial state. We do that by having the RTL reset all your variables based on the magic structures passed.

Looking back, those structures probably should have been some base address and a bunch of offsets, but I was't involved in those decisions.

There isn't much you can do to prevent COBOL from creating them. The compiler *could* be changed, but that is pretty low on the list given those relocations are a one-time event. Plus the RTL would have to handle older .EXE files and new .EXE files. Gets even nastier trying to mix old and new .OBJ files together.

[Hoff]

Around cases of system and (in this case) application performance investigations, I'd suggest a more systematic approach.

In this case, toss something like the DECset PCA tool or an analog at this application, and find out where the application is actually spending its time.

And as for the fixups, that depends on how many image activations you do per unit time, and whether that's a central cost. Image activations are comparatively expensive on OpenVMS, though there are techniques (installations, reduced numbers of image activations, splitting up big images into pools of servers and into lighter-weight UI tools, etc) that can be used to reduce the overhead.

[John McL]

These responses have indicated that more detail is required in some areas.

The applications are on Alpha. The number of executions of all images that might be impacted runs into the thousands per day. The executables are all Cobol and the shareable images they access might be in Cobol or in C. As I said, many of these images have thousands of quadword relocations so all up there's a lot of image activations going on.

I have discovered that the Cobol compiler generates a lot of .ADDRESS instructions and the main culprit seems to be the LINKAGES section. (I was surprised that the pass by reference system didn't generate machine code like Fortran does.)

I also suspect that quadword relocations are created when moving to a subprogram (i.e. with a PERFORM statement). I've also found that even when I work totally in C some quadword relocations are created when I call functions external to my code (e.g. access the various standard run-time libraries).

These quadword relocations seem to be a performance hit. No response has indicated exactly what's involved with resolving them. Is just one PSECT, $LINK$ accessed or must other PSECTs such as $CODE$ be read and resolved? How fast can Alphas process these? Are we talking 1000/second or 10 times that number? In short, what kind of hit are these executables taking? (Which of course will dictate if it's worth making an effort to improve the situation.)

Assuming the performance hit is worth addressing, what options do I have?

It was suggested to me that having the COBOL program specify the data as EXTERNAL might reduce the number of relocations. Any thoughts?

Are any COBOL compiler qualifiers likely to help? (None seem obvious candidates.)

Would the introduction of global sections for a lot of this data be any help?

Would INSTALL / RESIDENT images help? I think there's too many images to do that for all but it may be feasible to install some of them.

I thank those responding so far but I think the responses haven't advanced things very far.