T.R | Title | User | Personal Name | Date | Lines |
---|
2583.1 | A Little Light! | AIMTEC::BUTLER_T | | Fri Apr 16 1993 19:21 | 10 |
| A1$DEFER lets the stubs for shareable images to be linked with the
main image rather than linking the shareable images.
Now, according to what I have read, this is supposed to result in
a performance improvement since the shareable images are only
activated when needed.
HTH,
Tim
|
2583.2 | Where has Andrew been all week? | AIMTEC::WICKS_A | on the Streets of San Francisco | Fri Apr 16 1993 20:13 | 11 |
| Tim,
I presume that the base note means setting A1$DEFER to 0 i.e off
which is an SRA requirement.
P.S I'm off the net for at least another week for anyone expecting me
to answer any other notes.
Regards,
Andrew.D.Wicks
|
2583.3 | Deferred images 101 | IOSG::TALLETT | Gimmee an Alpha colour notebook... | Fri Apr 16 1993 20:51 | 24 |
|
Indeed. Deferred image activation is a technique whereby the
shareable images that ALL-IN-1 wants to link against are
analysed at link time (thats what that subprocess is during
A1LINK) and a "stub" built which has all the same entry
points as the shareable image but none of the code. When
ALL-IN-1 is activated, only the stub gets activated so none
of the shareable image code is loaded or mapped. Only when
ALL-IN-1 actually tries to CALL the routine (eg if you use
the DTR features then it tries to call the DTR shareable) then the
stub gets called and a small piece of code in the stub maps
the real shareable image into memory and revectors all the entry
points into it.
The result is you get faster image activation and only take the hit
on a shareable image activation if you actually call it (which a
lot of the time you don't).
Its a pity this isn't a standard VMS feature as it is on other
operating systems (eg Windows). ALL-IN-1 links to so many images
that ALL-IN-1 engineering had to come up with a private scheme.
Regards,
Paul
|
2583.4 | more... | IOSG::MARCHANT | I'd sink therefore I swam | Sun Apr 18 1993 23:28 | 21 |
| So why does SRA want to turn this feature off? Well, that's because SRA
wants to include the SQL services shareable image into ALL-IN-1. If
deferred image activation is enabled (which it is by default,) you cannot
link in any other shareable images, otherwise the VMS linker dies with a
lot of multiple symbol definition errors. To get round this, SRA requires
that the link is performed with deferred image activation disabled.
Ideally, SRA should add the SQL services shareable image to the list of
images ALL-IN-1 produces stubs for. However, there is no way to do this
other than by editing A1LINK.COM - which of course is unsupported.
Another reason why SRA doesn't use the deferred image activation might
be (I don't know enough about SRA to say for sure) that it falls foul
of a restriction of the deferred image activation. Some shareable images
(e.g. VAXCRTL) contain data as well as code. However, these data sections
are not supported by the deferred image code, so any program wanting to
access these data sections can't (they can try, but the data will have
rubbish values.)
Cheers,
Paul.
|
2583.5 | Something(s) not installed /SHARE perhaps? | IOSG::SHOVE | Dave Shove -- REO2-G/M6 | Tue Apr 27 1993 12:05 | 19 |
| To answer the original question (about performance):
Normally, the main effect of not having deferred image activation
should be a large increase in image activation time (because the poor
old VMS image activator has far more work to do.) Typically, ALL-IN-1
start-up time can double.
However, once you've gone through this pain, the only effect during
running will be more image sections and pages in your virtual address
space. Since these should all be shared, there shouldn't be much
effect on performance.
I would check that everything is installed (as in $INSTALL) /SHARE
(check the output from $INSTALL /LIST). Maybe some SYSGEN parameter is
too low and you're getting errors from the $INSTALLs during system
startup. Also check that all the .EXEs which are $INSTALLed /SHARE have
world:read (or probably :execute) protection.
Dave.
|