home *** CD-ROM | disk | FTP | other *** search
/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 375.lha / IncrStorageManager_v1.0 / README < prev    next >
Text File  |  1990-05-02  |  5KB  |  133 lines
  1. PRODUCT: Incremental Storage Manager
  2.  
  3.  
  4. VERSION: 1.0
  5.  
  6.  
  7. AUTHOR:
  8.      Daniel B. Hankins
  9.      143 Montgomery Street
  10.      Poughkeepsie, NY 12601
  11.      dan-hankins@cup.portal.com
  12.  
  13.  
  14. CREATION DATE: 1989
  15.  
  16.  
  17. RELEASE  DATE: November 21, 1989
  18.  
  19.  
  20. NOTICE OF INTELLECTUAL PROPERTY:
  21.      This material is *NOT COPYRIGHTED*.  By this notice, I hereby place
  22. this program and all its parts in the public domain, under the definitions
  23. and restrictions of United States law.
  24.  
  25.  
  26. HISTORY OF REVISIONS:
  27.      None yet.
  28.  
  29.  
  30. FILE DISTRIBUTION:
  31.      README            FreeHandle.def
  32.      Build.Rexx            FreeHandle.mod
  33.      DynamicItem.def        HandleCollection.def
  34.      DynamicItem.mod        HandleCollection.mod
  35.      DynItem.def        Storage.def
  36.      DynItem.mod        Storage.mod
  37.      DynItemList.def        WordAlign.def
  38.      DynItemList.mod        WordAlign.mod
  39.      DynTest.mod
  40.  
  41.  
  42. WHAT IT CAN DO FOR YOU:
  43.  
  44.      This set of modules constitutes a storage manager with garbage
  45. collection for Modula-2 programs.  It is written in TDI Modula-2 for the
  46. Amiga, but should be easily portable to other implementations and
  47. architectures.
  48.      It uses *INCREMENTAL* garbage collection.  Most garbage collectors
  49. create and destroy items willy-nilly until storage is exhausted.  Then they
  50. hold up all other processing while they copy all the in-use items down to
  51. one end of the storage space, thus freeing up the rest of the space for more
  52. items.
  53.      In incremental garbage collection, a few items are copied every time a
  54. New() or Dispose() is done.  This results in overhead which in total is
  55. larger than that of stop-and-copy methods, but which never causes the
  56. system to halt while collection is done.  This is far more suitable for
  57. programs which require real-time response or close to it.
  58.      Also, most storage managers begin with a statically sized storage
  59. space and allocate from that.  This requires the user to guess before
  60. running a program that uses storage management how much storage is going to
  61. be needed.  Guess too small, and the program aborts.  Guess too large, and
  62. storage is wasted; other programs can't get space to run in.
  63.      This storage manager frees the user from these considerations, and is
  64. a good system citizen in the bargain; it allocates storage in blocks of
  65. 1K granularity from the operating system, and suballocates from these. 
  66. Whenever a block becomes unused, the manager returns it to the system.
  67.  
  68.  
  69. HOW TO USE IT:
  70.  
  71.      The procedures which perform the services of the manager are defined
  72. in DynamicItem.def.  Build.Rexx contains an ARexx program that will build
  73. the link and symbol files for the manager in the correct order (provided
  74. you are using TDI Modula-2).  Just import the procedures and types you want
  75. from DynamicItem, and you'll be in business.
  76.      The module DynTest.mod is included for those that would like to see it
  77. work for themselves;  I used it to test the services.
  78.  
  79.  
  80. BUGS AND CAVEATS:
  81.  
  82.      I've tested the code pretty thoroughly, so I don't think there are any
  83. bugs in it.  If you find some, let me know via snail mail or Usenet mail. 
  84. The addresses are listed at the top of the file.  Or just post in
  85. comp.sys.amiga;  I read it fairly often.
  86.      Performance is probably not all that great;  I organized the code in a
  87. *very* object oriented way, in order to make development easier on myself,
  88. and to make the code easier to read for those who'd like to fiddle with it.
  89. As a result, there are many procedures which consist of one, two or a very
  90. few statements.  This adds considerably to the procedure call overhead.
  91.  
  92.  
  93. PLANS AND FUTURE FEATURES:
  94.  
  95. * Single-module version
  96.      I am in the process of developing a single-module version of this
  97. program, with procedures made in-line where appropriate.  That version will
  98. be distributed along with the object-oriented version.  Future improvements
  99. will be made in parallel to both versions.
  100.  
  101. * Granularity control
  102.      I plan to introduce a variable which the programmer can change to
  103. indicate with what granularity storage should be allocated from the
  104. operating system.  The minimum granularity, 1K, is hard-wired into the code
  105. at present.  The programmer will be able to change this to 2K or 4K or 37K
  106. or whatever.
  107.  
  108. * Last-ditch stop-and-copy
  109.      I plan to add code which handles the eventuality where no more storage
  110. can be gotten from the operating system, but not all unused space has been
  111. reclaimed from existing storage blocks.  The new code will attempt to
  112. rearrange items in the existing blocks in order to make room for the new
  113. item.  Currently the code checks existing blocks for unused space.  If it
  114. cannot find what it needs there, then it attempts to allocate storage from
  115. the operating system.  If that fails, NIL is returned.  The new code will
  116. add another level of attempt.
  117.      The new feature will be able to be switched on and off by means of a
  118. control variable.
  119.  
  120.  
  121. THE LAST WORD:
  122.  
  123.      I hope this is of use to Modula-2 programmers.  Send comments, kudos,
  124. insults, gifts, and flames to the addresses listed at the top of this file.
  125. Share and Enjoy!
  126.  
  127.  
  128. THE WORD AFTER THE LAST WORD:
  129.  
  130.      "Darrell suspected someone had once again slipped him a spoon with the
  131. concave side reversed."
  132.      - Gary Larson, The Far Side
  133.