Operating System - OpenVMS
1748181 Members
3691 Online
108759 Solutions
New Discussion юеВ

Re: Quadword relocations - what are they?

 
SOLVED
Go to solution
John McL
Trusted Contributor

Re: Quadword relocations - what are they?

Just briefly ... I've just discovered that the LINKAGE section in Cobol is to obtain the addresses of parameters passed into the current code from a calling program (i.e. not for the current code to make its own calls).

By making this clear maybe I'll save respondents going down certain useless paths.
Phil.Howell
Honored Contributor

Re: Quadword relocations - what are they?

There may be some overhead, but IMHO this will be insignificant in the context
of overall system operation.
see this section in the linker manual
http://h71000.www7.hp.com/doc/83final/4548/4548pro_021.html#index_x_559

The link option /shared=address_data may help but I have never used this
option.

You should (depending on available memory) make sure all shared images are
installed, and the more frequently used executable images.
John Reagan
Respected Contributor

Re: Quadword relocations - what are they?



For C programs calling external routines (actually ANY program calling external routines), the compiler and linker don't know where LIB$GET_VM will eventually reside. So the compiler allocates a quadword in the $LINKAGE$ section and asks the linker to put the address of LIB$GET_VM there. Of course, the linker doesn't know either so it leaves relocation info for the image activator. You have these on all systems (do man ld and man loader on your Unix/Linux system).

For COBOL... COBOL likes address constants, no wait, thats wrong. COBOL LOVES address constants. COBOL is addicted to address constants!

Besides the data structures to re-initialized variables for CANCEL, there are two other big areas.

- For regular initialization, the compiler passes the start/end addresses to a DCOB$ initialization routine (or LIBOTS routine). Since the compiler doesn't know the final address of your data, it allocates quadwords in the $LINKAGE$ section and asks the linker to compute the final address. For regular images, the linker can figure it out. For shareable images, even it doesn't know. It leaves relocations for the image activator.

- For PERFORM, COBOL paragraphs don't know if they should "return" or "fall through". Consider:

PERFORM A.
PERFORM A THRU B.

On the first call to A, it needs to "go back". On the second call, it needs to "fall through" to B. How does it know? You guessed it. Address constants!

At each PERFORM, the compiler shoves the address of the "last" paragraph into a special compiler-generated location. Each paragraph checks this special location against its own address to see where to go next. The result, lots of address constants for code labels.

As mentioned earlier, these relocations are only done once at image activation time. If the program stays running for any length of time, the overhead isn't large. If you run over and over again, it can be noticable.

You might want to install with /OPEN /HEADER and /SHARED. You might also want /RESIDENT (which requires linking with /SECTION_BINDING). A larger XFC cache can't hurt either.
John Reagan
Respected Contributor

Re: Quadword relocations - what are they?

Oh, you asked if there are any COBOL qualifiers to help. Nope. Sorry.

We did so some work on I64 to reduce the number of address constants since there is a relatively small limit in the short-data section. However, on Alpha, there is no actual limit, just your gag reflex on the size and overhead for the address constant relocations. We didn't take that support back to Alpha (it was platform-specific inside the code-generator).

COBOL in shareable images is just painful with respect to address constant relocations.
John McL
Trusted Contributor

Re: Quadword relocations - what are they?

John R,

I've spent the last few hours discovering what you've just told me. Either Grace Hopper or some Digital people have a lot to answer for ;-)

Many of these images will be installed /OPEN/HEADER/SHARED but what does that really save apart from the disk I/O and the potential ability to share the data (if we want that)? I also can't see exactly what advantage /RESIDENT gives apart from what seems to be a contiguous chunk of virtual memory.

Is $IMGFIX run across the images when they are installed in order to resolve as many references as possible? That's the kind of thing we need.

I'd rather not have to break the news that we need to radically redesign of our business processes and code so that more work is done per image activation.
Hoff
Honored Contributor

Re: Quadword relocations - what are they?

INSTALL is the user-accessible portion of the $imgact image activation service; INSTALL pre-activates the image.

Once the image activation processing starts in earnest, the $imgfix then occurs, since the fix-ups aren't known until the images are mapped into the process address space. AFAIK, there's no way to perform the fix-ups until after the executable image and all of the constituent (installed or otherwise) shareable images are all stacked into process virtual address space, and that doesn't happen during the INSTALL processing.

http://h71000.www7.hp.com/doc/83final/4548/4548pro_020.html#fixup_sec

John Gillings
Honored Contributor
Solution

Re: Quadword relocations - what are they?

John,

>installed /OPEN/HEADER/SHARED but what
>does that really save apart from the disk
>I/O and

Sharing writeable data is a special case, but sharing code and readonly data can be a big win if you have many processes executing the same images simultaneously. You save on memory, because there's only one copy, and pagefaults because a page you want may be in the working set of another process, so you get a global valid fault rather than a hard fault.

> I also can't see exactly what
>advantage /RESIDENT gives apart from what
>seems to be a contiguous chunk of virtual
>memory.

The code is physically resident, so it's paged in at INSTALL time. No pagefaults required for references. It's also mapped into S0/S1 space, so the addresses are the same for all processes and fixed at installation time. That means you it's not necessary to perform relocations. The cost is physical memory, which is getting cheaper and cheaper.

Also look at /SHARED=ADDRESS_DATA. From HELP:

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

All this presupposes that the time to perform the fixups and the number of image activations are significant enough to worry about.

Try writing a test program that just activates your shareable images then exits immediately. Compare the execution times with different combinations of installed images and different options.

Depending on what the images do, it may be better to try to keep the image running longer (for example, put a menu or event loop into the image, rather than in a DCL jacket). As Hoff suggests, another approach is to go "client server". Have the heavy weight processing in a long lived server process, with a lightweight client feeding it requests and catching results. The (lower) cost of starting and stopping the client may compensate for the cost of interprocess communications.
A crucible of informative mistakes
John McL
Trusted Contributor

Re: Quadword relocations - what are they?

To Hoff (Feb 26, 01:06),

I realised what I was asking after I had posted. Life would be a lot easier if, as John R said, Cobol used offsets. Even the literals are set up with .ADDRESS and can't be resolved until activation.


To John G,

I've used installed images many times in the last 29 years :-) but I haven't worked with /RESIDENT images. I understood that the only way to replace them was with a reboot but that's not an option here because changes are frequently made to the shareable images and they need to be replaced.

The use of /SHARED_ADDRESS looks potentially useful but I wonder how well it works with COBOL. It's something I'll try today or tomorrow, likewise a test program that accesses these COBOL shareable images and then exits (to determine what the activation overhead really is).

Your other suggestions refer to a major redesign. We'd prefer not to go that way but it looks like we may not have a choice.
Phil.Howell
Honored Contributor

Re: Quadword relocations - what are they?

What leads you to think that the image activation fixups are causing a performance problem?
Do you have lots (more than 100) of symbol_vectors in the link options for your sharable images?
Phil

To JR
on the other side of the world we usually stick the reply text in our paste buffer for when itrc fails (again) I thought you might get better response locally.
John McL
Trusted Contributor

Re: Quadword relocations - what are they?

Phill,

When the number of quadword relocations is over 5000 I think there's a good chance that activation will be time-consuming, and we have plenty of such images. By the way, that figure comes from the shareable image so any image that references it will also have its own quadword relocations to be resolved.

We have quite a number of Symbol Vectors defined for the Link of the shareable image but I don't believe it would above 50 in any one shareable. Would that really make a difference when the activation can't distinguish the entry points that we might access from those that we don't?