home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / hp48 / 5866 < prev    next >
Encoding:
Text File  |  1992-11-21  |  2.4 KB  |  64 lines
  1. Newsgroups: comp.sys.hp48
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!mercury.unt.edu!sol!cgw
  3. From: cgw@sol.acs.unt.edu (christopher williams)
  4. Subject: Re: Strange Memory Loss
  5. Message-ID: <cgw.722377081@sol>
  6. Originator: cgw@sol.acs.unt.edu
  7. Sender: usenet@mercury.unt.edu (UNT USENet Adminstrator)
  8. Organization: University of North Texas
  9. References: <cgw.722287417@sol> <1ejq7bINNgem@uwm.edu> <cgw.722303141@sol> <1elm1lINNs9i@lily.csv.warwick.ac.uk>
  10. Date: Sat, 21 Nov 1992 20:18:01 GMT
  11. Lines: 51
  12.  
  13. In <1elm1lINNs9i@lily.csv.warwick.ac.uk> phudl@csv.warwick.ac.uk (Mr S J Liddicott) writes:
  14. >I find that MEM does not do carbage collection at all.
  15. >If I do lots of MEMs in succession, on of them gives a suddenly 
  16. >much higher (probably the true) value.
  17.  
  18. yep, that's gc at work. think about it: if you have LAST STACK, ARG,
  19. and CMD all enabled, they're going to suck up a little bit of memory.
  20. by typing MEM repeatedly, you replace what _used_ to be in those,
  21. and as soon as everything holds MEM (or a result thereof), you 
  22. get a slightly bigger value. [at least, that's the theory *i've* 
  23. always used to explain why that happens]
  24.  
  25. for example, here's a list of the values i get when i type 
  26. MEM, record it, then DROP the result a few times:
  27.  
  28. 8457.5
  29. 8433
  30. 8411
  31. 8411
  32.  
  33. you can [probably?] prove that this is the case by turning off
  34. LAST STACK, ARG, and CMD, putting 0 on the stack several times, 
  35. clearing the stack, then typing MEM and DROP a few times: the 
  36. first value you get for MEM is the same as the last value.
  37.  
  38. furthermore, putting a medium-sized matrix on the stack ( { 12 3 }, 
  39. 303 bytes), doing MEM, dropping it, then repeating the first step 
  40. above, gives these values:
  41.  
  42. 8100    (matrix on stack)
  43. 8115.5  (clear stack)
  44. 8409
  45. 8411
  46. 8411
  47.  
  48. at the second number, the matrix is still held in LAST STACK; after
  49. i type MEM, it is replaced with the result for MEM. [if this is all
  50. totally wrong, it's because i've only been up for an hour]
  51.  
  52. >What is the SYSEVAL to force garbage collection.  If that is tried,
  53. >when the problem occurs we can see if is the cure.  Though I don't
  54. >think the 48 should have refused to perform an operation because of
  55. >low memory without attempting to get it back with garbage collection.
  56.  
  57. as i understand it, the HP48 *does* do gc; this is the reason for 
  58. occasional pauses in operations. i do know that this is the case
  59. with the 28s.
  60.  
  61. but back to the original question: _where_ is 11k of my memory going?
  62.  
  63. -cgw-
  64.