Conference vaxaxp::vmsnotes

517.0. "effect of solitary on virtual image size?" by CSC32::J_HENSON (Don't get even, get ahead!) Wed Apr 23 1997 18:03

OpenVMS V6.2-1h3, alpha, linker

Can someone explain to me why the size of an image would be radically
different when linked with an options file that forces the solitary
attribute to large psects as opposed to one that forces the page
attribute to the same psects?  Take the following as an example.

$create big.c
int ibig_array[100000];
float fbig_array[100000];
double dbig_array[100000];
struct {
	int i_array[100000];
	float f_array[1000000];
	double d_array[100000];
	} big_structure;
main(){}
$cc/extern=common/share big
$link/map=big_page.map/full big,sys$input/opt
psect_attr = ibig_array,page
psect_attr = fbig_array,page
psect_attr = dbig_array,page
psect_attr = big_structure,page
$!
$link/map=big_solitary.map/full big,sys$input/opt
psect_attr = ibig_array,solitary
psect_attr = fbig_array,solitary
psect_attr = dbig_array,solitary
psect_attr = big_structure,solitary
$

If you compare the maps generated by these two link command, and look
under Image Synopsis, you will see that the Virtual Memory Allocated
for the image linked with solitary is roughly twice that for the
image linked page.  Why is that?  Does this have any special significance
for run-time performance?

FWIW, the size of the images created is the same for both.

Thanks,

Jerry

Solitary means that there cannot be any overlap for the next
page of memory.  In order to accomplish that, the idea is
that you get a 'blank' piece of memory between each new
image section.  These sections are also based on the largest
pagesize for alpha, 65536 (0x10000).

So, not only are the image sections aligned on 65535 byte boundaries
there is at least one page between each image section. 
You can reduce this with the /BPAGE qualifier and using
/BPAGE=13 (default is 16).

I would QAR/IPMT this however, because it looks like the linker
is adding the size of the previous section and not the pagesize to get 
the next image section base address.

The size of the actual .EXE is not affected because these image sections
are demand zero sections and take no disk space.  I do not
believe there to any additional performance hit for
the blank holes any more than there is for the default 8K hole
in address space at the beginning of every OpenVMS image.