home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20016 < prev    next >
Encoding:
Text File  |  1992-12-29  |  4.1 KB  |  86 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!spool.mu.edu!uwm.edu!linac!unixhub!slacvx.slac.stanford.edu!fairfield
  3. From: fairfield@slacvx.slac.stanford.edu
  4. Subject: Re: ballooning EXE size
  5. Message-ID: <1992Dec29.111631.1@slacvx.slac.stanford.edu>
  6. Lines: 74
  7. Sender: news@unixhub.SLAC.Stanford.EDU
  8. Organization: Stanford Linear Accelerator Center
  9. References: <01GSUT89O7JK000J0I@XRT.UPENN.EDU>
  10. Date: Tue, 29 Dec 1992 19:16:31 GMT
  11.  
  12. In article <01GSUT89O7JK000J0I@XRT.UPENN.EDU>, BUHLE@XRT.UPENN.EDU ("E. Loren Buhle, Jr. [-662-3084]", 215) writes:
  13. >I have a problem with the size of an executable going from ~1,000 blocks to 
  14. >something on the order of 75,000 blocks. 
  15. >
  16. >What am I doing? I am charged with writing a small interface to some existing 
  17. >FORTRAN code. I have no control over the existing FORTRAN code and can only 
  18. >say that it makes extensive use of VAX-FORTRAN Structure/record/map 
  19. >statements. I don't own the large body of FORTRAN code and really don't 
  20. >relish the thought of rewriting it...
  21. >
  22. >When the FORTRAN interface stub subroutines (e.g. subroutines that print a 
  23. >"not implemented" message and return) are replaced with my code, the resulting 
  24. >executable goes from ~1,000blocks to ~75,000 blocks. 
  25.  
  26.     First question: are you refering to the size of the .EXE file on disk,
  27.     or the size of the running image in memory?  I'll assume the former.
  28.  
  29. >Yes, I use some scratch arrays (scratch arrays defined as local to the 
  30. >subroutine), so I replaced these with LIB$GET_VM and LIB$FREE_VM and the 
  31. >executable size when back to ~1,100 blocks. I presume the difference is due to 
  32. >my code size. Ok so far, but I can't get away with this for long....
  33.  
  34.     You haven't told us what you're doing  in "my code".  If your code was
  35.     Fortran  (which  I  take  it, it is not), and if  you  declared  local
  36.     arrays, and if  you  initialized  _any_portion_  of  those  arrays  to
  37.     non-zero  values,  then  you would get the behaviour you've described.
  38.     If you're writing in C, and the  arrays are static, and you initialize
  39.     any  portion  of  them  to non-zero values, I would  expect  the  same
  40.     situation.
  41.  
  42.     Reason: the VMS linker normally  will  not allocate blocks in the disk
  43.     file  (.EXE file) for uninitialized memory.  These are referred to  as
  44.     "demand zero pages".  Only when the  image  is  activated  is  virtual
  45.     memory  allocated  for  such  memory.   However,  if  you initialize a
  46.     portion of an array, the  linker  is  prevented from using demand-zero
  47.     pages and the whole, initialized array is expanded in the .EXE file.
  48.     
  49. >
  50. >Eventually, the addition of the simplest code causes the executable to go from 
  51. >1,100 blocks to ~76,000 blocks. Looking at the LINK map, the size of my 
  52. >interface modules are quite small. Remember, this is FORTRAN and most of the 
  53. >memory is statically allocated.
  54. >
  55. >It would seem that I'm crossing some kind of boundary in terms of virtual
  56. >memory usage and am reserving space in the executable file. This is merely a
  57.  
  58.    I don't think so...
  59.  
  60. >hunch and I'd like to query info-vax for an explanation and any possible
  61. >solutions. Yes, I use all the sharable portions of FORTRAN and C (there is 
  62. >some C in my interface, but I observe the same behavior when the C routines 
  63. >are "dummied" out) as follows:
  64. >
  65. >$link/map/exec=foo.exe
  66. > untouchable.olb/INC=foo_main, -    ! main calling routine
  67. > untouchable.olb/L, -        ! library of untouchable code objects
  68. > expm.olb/l, -            ! my interface routines
  69. > sys$input/opt
  70. >   SYS$SHARE:FORRTL.EXE/SHARE,sys$library:vaxcrtl.exe/share
  71. >
  72. >Thoughts? 
  73.  
  74.     Your LINK looks  fine,  although  I've  never  had  to  specify FORRTL
  75.     explicitly.    The  installed  shareable  images  in  SYS$LIBRARY  are
  76.     normally linked by default (although, I  know,  VAXC  is  aberrant  in
  77.     these and other respects).  Can we see a portion of your code?
  78.     
  79.         -Ken
  80. -- 
  81.  Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
  82.  SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
  83.  Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
  84.  ----------------------------------------------------------------------------
  85.  These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
  86.