home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20119 < prev    next >
Encoding:
Text File  |  1992-12-30  |  3.1 KB  |  58 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!paladin.american.edu!gatech!darwin.sura.net!haven.umd.edu!decuac!pa.dec.com!nntpd2.cxo.dec.com!adserv.enet.dec.com!winalski
  3. From: winalski@adserv.enet.dec.com (Paul S. Winalski)
  4. Subject: Re: ballooning EXE size
  5. Message-ID: <1992Dec30.221028.25252@nntpd2.cxo.dec.com>
  6. Lines: 45
  7. Sender: usenet@nntpd2.cxo.dec.com (USENET News System)
  8. Reply-To: winalski@adserv.enet.dec.com (Paul S. Winalski)
  9. Organization: Digital Equipment Corporation, Nashua NH
  10. References: <01GSUT89O7JK000J0I@XRT.UPENN.EDU> <1992Dec29.111631.1@slacvx.slac.stanford.edu>
  11. Date: Wed, 30 Dec 1992 22:10:28 GMT
  12.  
  13.  
  14. In article <1992Dec29.111631.1@slacvx.slac.stanford.edu>,
  15. fairfield@slacvx.slac.stanford.edu writes:
  16.  
  17. [regarding the problem of a FORTRAN program that suddenly needed 70 times
  18.  as many disk blocks for the .EXE after minor changes and a relink]
  19. |>
  20. |>    You haven't told us what you're doing  in "my code".  If your code was
  21. |>    Fortran  (which  I  take  it, it is not), and if  you  declared  local
  22. |>    arrays, and if  you  initialized  _any_portion_  of  those  arrays  to
  23. |>    non-zero  values,  then  you would get the behaviour you've described.
  24. |>    If you're writing in C, and the  arrays are static, and you initialize
  25. |>    any  portion  of  them  to non-zero values, I would  expect  the  same
  26. |>    situation.
  27. |>
  28. |>    Reason: the VMS linker normally  will  not allocate blocks in the disk
  29. |>    file  (.EXE file) for uninitialized memory.  These are referred to  as
  30. |>    "demand zero pages".  Only when the  image  is  activated  is  virtual
  31. |>    memory  allocated  for  such  memory.   However,  if  you initialize a
  32. |>    portion of an array, the  linker  is  prevented from using demand-zero
  33. |>    pages and the whole, initialized array is expanded in the .EXE file.
  34.  
  35. Not true.  Initialization of a portion of an array doesn't cause the whole
  36. array to be written to blocks in the disk file.  The Linker lays out memory for
  37. all program sections in the image, then it fills in the initial values for
  38. the code and initialized data, and then it scans the image looking for
  39. uninitialized pages.  Where it finds a run of uninitialized pages, it creates
  40. a new image section with the demand-zero attribute.  Demand-zero pages don't
  41. have to appear in the .EXE file, since by definition the system knows that they
  42. are all zeros.  This phase of the link is called "demand-zero compression".
  43.  
  44. Image sections do not come for free.  Your process can only have a certain
  45. number of them, given by the PROCSECTCNT SYSGEN parameter value.  To avoid
  46. creating too many image sections, the Linker stops doing demand-zero compression
  47. when the total number of image sections reaches the value set by the ISD_MAX
  48. linker option, the default value of which is 96.  This is what happened to the
  49. original poster.  His program has lots of little runs of uninitialized pages
  50. in it.  Something that he changed pushed the Linker over the ISD_MAX limit and
  51. it stopped creating demand-zero image sections.  One or more large,
  52. uninitialized arrays that occur in the image after that point thus weren't
  53. dzero-compressed and ended up on disk.
  54.  
  55. Steve Lionel's posting gave the solutions to this problem.
  56.  
  57. --PSW
  58.