From: fairfield@slacvx.slac.stanford.edu
Subject: Re: ballooning EXE size
Organization: Stanford Linear Accelerator Center
Date: Tue, 29 Dec 1992 19:16:31 GMT

In article <01GSUT89O7JK000J0I@XRT.UPENN.EDU>, BUHLE@XRT.UPENN.EDU ("E. Loren Buhle, Jr. [-662-3084]", 215) writes:
>I have a problem with the size of an executable going from ~1,000 blocks to 
>something on the order of 75,000 blocks. 
>
>What am I doing? I am charged with writing a small interface to some existing 
>FORTRAN code. I have no control over the existing FORTRAN code and can only 
>say that it makes extensive use of VAX-FORTRAN Structure/record/map 
>statements. I don't own the large body of FORTRAN code and really don't 
>relish the thought of rewriting it...
>
>When the FORTRAN interface stub subroutines (e.g. subroutines that print a 
>"not implemented" message and return) are replaced with my code, the resulting 
>executable goes from ~1,000blocks to ~75,000 blocks. 

    First question: are you refering to the size of the .EXE file on disk,
    or the size of the running image in memory?  I'll assume the former.

>Yes, I use some scratch arrays (scratch arrays defined as local to the 
>subroutine), so I replaced these with LIB$GET_VM and LIB$FREE_VM and the 
>executable size when back to ~1,100 blocks. I presume the difference is due to 
>my code size. Ok so far, but I can't get away with this for long....

    You haven't told us what you're doing  in "my code".  If your code was
    Fortran  (which  I  take  it, it is not), and if  you  declared  local
    arrays, and if  you  initialized  _any_portion_  of  those  arrays  to
    non-zero  values,  then  you would get the behaviour you've described.
    If you're writing in C, and the  arrays are static, and you initialize
    any  portion  of  them  to non-zero values, I would  expect  the  same
    situation.

    Reason: the VMS linker normally  will  not allocate blocks in the disk
    file  (.EXE file) for uninitialized memory.  These are referred to  as
    "demand zero pages".  Only when the  image  is  activated  is  virtual
    memory  allocated  for  such  memory.   However,  if  you initialize a
    portion of an array, the  linker  is  prevented from using demand-zero
    pages and the whole, initialized array is expanded in the .EXE file.
    
>
>Eventually, the addition of the simplest code causes the executable to go from 
>1,100 blocks to ~76,000 blocks. Looking at the LINK map, the size of my 
>interface modules are quite small. Remember, this is FORTRAN and most of the 
>memory is statically allocated.
>
>It would seem that I'm crossing some kind of boundary in terms of virtual
>memory usage and am reserving space in the executable file. This is merely a

   I don't think so...

>hunch and I'd like to query info-vax for an explanation and any possible
>solutions. Yes, I use all the sharable portions of FORTRAN and C (there is 
>some C in my interface, but I observe the same behavior when the C routines 
>are "dummied" out) as follows:
>
>$link/map/exec=foo.exe
> untouchable.olb/INC=foo_main, -	! main calling routine
> untouchable.olb/L, -		! library of untouchable code objects
> expm.olb/l, -			! my interface routines
> sys$input/opt
>   SYS$SHARE:FORRTL.EXE/SHARE,sys$library:vaxcrtl.exe/share
>
>Thoughts? 

    Your LINK looks  fine,  although  I've  never  had  to  specify FORRTL
    explicitly.    The  installed  shareable  images  in  SYS$LIBRARY  are
    normally linked by default (although, I  know,  VAXC  is  aberrant  in
    these and other respects).  Can we see a portion of your code?
    
    	-Ken
-- 
 Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
 SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
 ----------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
Newsgroups: comp.os.vms