home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / question / 10767 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  3.1 KB
  1. Path: sparky!uunet!cs.utexas.edu!uwm.edu!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!sm86+
  2. From: sm86+@andrew.cmu.edu (Stefan Monnier)
  3. Newsgroups: comp.unix.questions
  4. Subject: Re: Does free() really free?
  5. Message-ID: <oeeD5OC00awMEEimk2@andrew.cmu.edu>
  6. Date: 5 Sep 92 09:41:46 GMT
  7. Article-I.D.: andrew.oeeD5OC00awMEEimk2
  8. References: <9209051620.AA02618@ucbvax.Berkeley.EDU>
  9. Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
  10. Lines: 58
  11. In-Reply-To: <9209051620.AA02618@ucbvax.Berkeley.EDU>
  12.  
  13. Excerpts from netnews.comp.unix.questions: 5-Sep-92 Does free() really
  14. free? Simon Marshall@sequent.c (1471)
  15.  
  16. > Or: How do I find out the real size of a running process?
  17.  
  18. >     Hi all.  This is really a question about the Sequent's shfree(), but
  19. >     in tests it seems to apply to other machines and free() in general.
  20. >     Please can anyone give a knowledgable answer?
  21.  
  22. >     If I malloc(), then free(), the SZ (SIZE) column of ps does not show
  23. >     the expected fall.  I don't believe that the system ignores freed space,
  24. >     but then again I know that software that I have written thrashes
  25. >     machines, despite the fact that most of the memory malloc()ed is
  26. >     subsequently free()ed.
  27.  
  28. >     On our Sequent and Suns, for example, once the SZ column shows
  29. >     70Meg+, you can see the machines thrash.  But I can work out that the
  30. >     actual unfreed memory only amounts to at most 15Meg.
  31.  
  32. >     So, please could anyone tell me what is going on here?  Does free()
  33. >     actually free, and is the SZ column of ps reliable in any way?  Or is
  34. >     free() working as expected, ps lying, but 15Meg is too much?  Surely
  35. >     not?!  I'd welcome anything emailed/posted.  (Except unhelpful questions
  36. >     of the order `why are you mallocing then freeing so much' etc. :-)
  37.  
  38. >     Thanks in advance, Simon.
  39. > _______________________________________________________________________________
  40. >  Simon Marshall, Dept. of Computer Science, University of Hull, Hull HU6
  41. > 7RX, UK
  42. >   "Football isn't about life and death.  It's more important than that." Bill
  43. > Email: S.Marshall@Hull.ac.uk    Phone: +44 482 465181    Fax: 466666   Shankley
  44.  
  45.  
  46. I'm not a Unix wizard: I used to have an Atari ST.
  47.  
  48. But Unix may be a bit the same on this point:
  49. A alloc() is not a call to the OS but a library function. This
  50. function request memory from the OS but in 'big' blocks 
  51. (cause the malloc() of the OS is a bit too complex, especially
  52. on Unix, where it has to deal with VM...). 
  53. When there is some place left in one of the blocks, the alloc()
  54. just returns it (and marks it busy), else, it calls malloc() to
  55. get a new block and marks the needed part of it as busy.
  56.  
  57. When you call free(), it will mark the corresponding region as 
  58. free. But the block in which that region is may not be fully
  59. free, so that it is not released to the OS: it is free for the 
  60. prg but not for the OS.
  61.  
  62. This is maybe what is happening to you: your 15MB are 
  63. distributed among 70MB of blocks !
  64.  
  65.  
  66.     Stefan Monnier
  67.  
  68. -----------------------------------------------------
  69. -- On the average, people seem to be acting normal --
  70. -----------------------------------------------------
  71.