home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20042 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  3.3 KB
  1. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: RE: ballooning EXE size
  5. Message-ID: <9212291417.AA07008@uu3.psi.com>
  6. Date: 29 Dec 92 13:16:44 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 65
  11.  
  12.  
  13.     I have a problem with the size of an executable going from ~1,000
  14.     blocks to  something on the order of 75,000 blocks. 
  15.  
  16.     What am I doing? I am charged with writing a small interface to some
  17.     existing  FORTRAN code. I have no control over the existing FORTRAN
  18.     code and can only say  that it makes extensive use of VAX-FORTRAN
  19.     Structure/record/map statements. I  don't own the large body of
  20.     FORTRAN code and really don't relish the thought of  rewriting it...
  21.  
  22.     When the FORTRAN interface stub subroutines (e.g. subroutines that
  23.     print a "not  implemented" message and return) are replaced with my
  24.     code, the resulting  executable goes from ~1,000blocks to ~75,000
  25.     blocks. 
  26.  
  27.     Yes, I use some scratch arrays (scratch arrays defined as local to the
  28.     subroutine), so I replaced these with LIB$GET_VM and LIB$FREE_VM and
  29.     the  executable size when back to ~1,100 blocks. I presume the
  30.     difference is due to  my code size. Ok so far, but I can't get away
  31.     with this for long....
  32.  
  33.     Eventually, the addition of the simplest code causes the executable to
  34.     go from  1,100 blocks to ~76,000 blocks. Looking at the LINK map, the
  35.     size of my  interface modules are quite small. Remember, this is
  36.     FORTRAN and most of the  memory is statically allocated.
  37.  
  38.     It would seem that I'm crossing some kind of boundary in terms of
  39.     virtual memory usage and am reserving space in the executable file.
  40.     This is merely a hunch and I'd like to query info-vax for an
  41.     explanation and any possible solutions. Yes, I use all the sharable
  42.     portions of FORTRAN and C (there is some  C in my interface, but I
  43.     observe the same behavior when the C routines are "dummied" out) as
  44.     follows:
  45.  
  46.     $link/map/exec=foo.exe
  47.      untouchable.olb/INC=foo_main, -    ! main calling routine
  48.      untouchable.olb/L, -        ! library of untouchable code objects
  49.      expm.olb/l, -            ! my interface routines
  50.      sys$input/opt
  51.        SYS$SHARE:FORRTL.EXE/SHARE,sys$library:vaxcrtl.exe/share
  52.  
  53.     Thoughts? 
  54.  
  55. You're running into a classic VMS "gotcha'".  All your uninitiallized COMMON
  56. blocks, as well as any other uninitialized data objects (like arrays that
  57. aren't on the stack - I'm not sure when VAX FORTRAN decides to put stuff on
  58. the stack) can appear in the image file as either a page of all zeroes, or as
  59. a request for a demand-zero section.  The Linker does "demand zero compres-
  60. sion" to locate groups of all-zero pages and convert them to demand-zero
  61. sections, which take up insignificant space in the executable image.  However,
  62. each demand-zero section requires an Image Section Descriptor (ISD).  There
  63. Linker has a limit, ISD_MAX, on the number of ISD's it is willing to create;
  64. once it reaches the limit, it just fills the image with zeroed blocks.
  65.  
  66. ISD_MAX can be changed with a linker option of the same name.  By default, it
  67. equals "approximately 96".  Try adding:
  68.  
  69.     ISD_MAX=150
  70.  
  71. to your Linker options file (the stuff after the LINK command above).
  72.  
  73. Further details can be found in the Linker manual's chapter on options files.
  74.  
  75.                             -- Jerry
  76.  
  77.