Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #27139
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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