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


Groups > comp.lang.forth > #27139

Re: Reclaiming Allocated Memory

From anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups comp.lang.forth
Subject Re: Reclaiming Allocated Memory
Date 2013-12-04 16:46 +0000
Organization Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID <2013Dec4.174638@mips.complang.tuwien.ac.at> (permalink)
References <5293458b$0$296$14726298@news.sunsite.dk>

Show all headers | View raw


Doug Hoffman <glidedog@gmail.com> writes:
>I have settled on staying with the allocate/resize/free model.  Perhaps 
>analogous to type-checking, which most Forths also don't have, when 
>using manual memory reclamation one simply has to be careful and to 
>thoroughly test.  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?  If you can detect a memory
leak, you can also collect garbage, so a memory leak detector is just
as complex.  If you can build a simple one, you can also build a
simple gargabe collector.

>One can have a 
>Forth GC or even a region based memory utility, but from what I have 
>seen the use of these are not at all straightforward and add a possibly 
>significant burden to the programmer.

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.

Region-based allocation is between garbage collection and FREE: You
allocate things in particular regions, and then free the whole region.

>0 [if]
>\ general object creation/destruction
> >heap ( "class-name" -- obj ) \ create object using ALLOCATE
><free ( obj -- ) \ destroy object using FREE, thus reclaiming memory
>
>\ possible string messages
>s+: ( ... n -- obj c-a u ) \ concatenate n strings
>@:  ( -- c-a u ) \ leave entire string on stack
>size: ( -- n ) \ size of string
>[then]
>
>: dir  ( -- c-a u ) s" my-folder/" ;
>: file ( -- c-a u ) s" my-file" ;
>
>\ Case 1) reclaim memory immediately
>: (open-path) ( ... n obj -- fileid obj )
>   s+: r/o open-file throw swap ;
>: open-path ( ... n -- fileid obj )
>   heap> string (open-path) ;
>
>file dir s" /" 3 open-path \ uses: /my-folder/my-file
><free \ => fileid
>
>
>\ Case 2) reclaim memory later
>: sdir  ( -- c-a u ) s" my-sub-folder/" ;
>
>file sdir dir s" /" 4 open-path \ uses: /my-folder/my-sub-folder/my-file
>value path2 \ => fileid
>...
>path2 <free \ performed anytime later

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.  It seems to me that you have to
keep the object around until you want to free the memory, which does
not seem easier than just keeping the address to be freed around, on
the contrary: S+: returns an object in addition to the address; with
classical FREE you don't need to maintain the object.

- 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 | NextPrevious 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