Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #27160

Re: Reclaiming Allocated Memory

Show all headers | View raw

Doug Hoffman <glidedog@gmail.com> writes:
>On 12/4/13 11:46 AM, Anton Ertl wrote:
>> Doug Hoffman <glidedog@gmail.com> writes:
>>> I find it helps greatly to use a simple tool during
>>> development to check for memory leaks.  It works well.
>>
>> What tool do you use and how simple is it?
[code snipped]
>The tool is inefficient and only meant for use during development 
>(analogous to an array index check).  Run the program and execute .MEM 
>to see if all pointers have been freed.  Example:
>
>: foo ( -- obj )
>   heap> string { s }
>   s" some" s !:
>   s" text" s add: s
>   ;
>
>foo dup @: type \ => sometext
>.mem
>0 13965088
>1 13734992
>2 unFREEd pointers
><free .mem
>0 unFREEd pointers

Ok, so this just lists all the unfreed memory, and you would use it at
the end of the program.  But right at the end of the program it just
costs (sometimes dearly, see below) to free memory, so you should not
free the memory reported by that tool, unless it should have been
freed earlier.  Unfortunately the use of such tools encourages
programmers to free everything at the end.

As for costing dearly: Mozilla used to consume huge amounts of memory
with some usage patterns, much of which was swapped out to disk.  When
I wanted to quit Mozilla, it took many minutes of disk activity
(making the rest of the computer sluggish) before it finally exited.
Apparently it went through all that memory it had allocated and freed
it (and paged it in in the process) and only then it exited (which
unmaps all the memory automatically without paging it in).

>> The whole point of both garbage collection and region-based memory
>> allocation is to reduce the burden on the application programmer, in
>> particular the burden of keeping track of ALLOCATEd things, and when
>> they can be FREEd.
>>
>> In particular, with garbage collection you ALLOCATE at will, and never
>> have to FREE.
>
>It would be wonderful if such a GC could work in Forth without extra 
>effort by and restrictions for the programmer.  But from what I've seen 
>the extra effort and restrictions that don't fit my programming style.

Yes, there are some restrictions on the way you keep the addresses of
allocated memory:

a) Such addresses must not reside (exclusively) on the return stack or
in a local.  That's because the garbage collector is a standard
program, and standard programs cannot access all of the return stack
and all locals.  With system-specific changes this restriction can be
lifted.

b) Such addresses in the dictionary must reside in places declared as
root-addresses.  Again, there is no standard way to access all of the
dictionary, but with system-specific changes one could use all of the
dictionary as potential roots; besides being non-standard, this would
lead to longer garbage collection times and possibly to more garbage
being kept around (from spurious pointers).

c) In the allocated memory the addresses must reside at naturally
aligned boundaries.  That's also a portability requirement (there is
hardware that requires this), but one could make it configurable (so
one could also treat unaligned cells as potential addresses on
hardware that supports this).  Dropping this requirement would again
slow the garbage collector down and possibly increase the garbage that
is kept around.

d) An allocated object is only kept alive by a pointer to the start of
the object.  This requirement could be dropped, again at a cost in
garbage collection time and at a potential increase in garbage that is
kept around.

Which of these restrictions don't fit your programming style?

>> I don't see any advantage from using an object here.  These examples
>> could be done just as easily with FREE.  I also don't see how this
>> makes freeing easier in other cases.
>
>The definition of <FREE is:
>
>: <free  ( obj -- ) dup free: free throw ;
>
>So the free: message is first sent to the object before the object 
>itself is FREEd.  This gives the object the ability to first FREE any 
>memory allocated within the object, nested to any level.  All objects 
>are designed to do the right thing in response to free:.  In the foo 
>example above one can see that <free resulted in two calls to FREE. 
>Granted, not much saving of effort there.  But if the object were an 
>array or list of allocated objects then a single <free could result in 
>thousands of calls to free.

Ok, so you are doing region-based allocation here, but use an object
as a region handle.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-11-25 07:41 -0500
  Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-11-25 07:04 -0800
    Re: Reclaiming Allocated Memory albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-11-25 16:16 +0000
      Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-11-25 09:03 -0800
        Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-11-26 06:30 -0500
          Re: Reclaiming Allocated Memory AKK <akk@nospam.org> - 2013-11-26 13:07 +0100
    Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-11-26 05:11 -0500
  Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-04 16:46 +0000
    Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-05 06:43 -0500
      Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-12-05 06:30 -0800
        Re: Reclaiming Allocated Memory albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-05 14:37 +0000
          Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-12-05 07:21 -0800
        Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-06 04:57 -0500
          Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-12-06 07:38 -0800
            Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-07 06:14 -0500
      Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-05 18:14 +0000
        Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-06 04:58 -0500
          Re: Reclaiming Allocated Memory Bernd Paysan <bernd.paysan@gmx.de> - 2013-12-06 17:30 +0100
            Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-07 05:59 -0500
              Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-07 11:57 +0000
                Re: Reclaiming Allocated Memory albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-07 17:48 +0000
                Re: Reclaiming Allocated Memory Bernd Paysan <bernd.paysan@gmx.de> - 2013-12-07 19:15 +0100
                Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-09 13:45 +0000
          Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-06 17:42 +0000

csiph-web