Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #11163
| From | vandys@vsta.org |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Memory management |
| Date | 2012-04-11 19:09 +0000 |
| Message-ID | <9um377FctdU1@mid.individual.net> (permalink) |
| References | (2 earlier) <slrnjoanr2.2o8.zbigniew2011REMOVE@Tichy.myhome.org> <4f8553cc.583439917@192.168.0.50> <slrnjoatf9.3sn.zbigniew2011REMOVE@Tichy.myhome.org> <7vydnZOKecRiXxjSnZ2dnUVZ_tqdnZ2d@supernews.com> <slrnjobrl5.46l.zbigniew2011REMOVE@Tichy.myhome.org> |
Zbiggy <zbigniew2011REMOVE@gmail.remove.com> wrote: > That could be "long term" target - but for today, I was only wondering about > possibility to "remove" something, that is "somewhere in the middle" of > vocabulary (assumption is, that on its words don't depend any other words). > And then how to reclaim that "hole", which appeared in the place of > "removed" words (and data). You're talking about something which Smalltalk has been doing since the 1970's; methods--like everything else--are objects. You can take the class:method association and atomically point it at a new method object. The old one can be garbage collected (and will, at least once any remaining pointers to it are retired). Not only could you do this, it was *the* way that methods were added and updated. When you booted a Smalltalk image, you were running bits in the 1990's with continuity back to the VM images built in the 1970's. It was only in the 1990's that the Smalltalk architects, now working on their "Squeak" implementation, went back and added "bootup" source code so they could rigorously document how all of the necessary state of the VM image had come into being. Until that point, there were data structures which were hand inserted in the 1970's and still depended upon in all VM's twenty years later. Lacking strong memory semantics with garbage collection, it's hard to design a bullet proof system of comparable ability. You can allocate colon definition memory dynamically, and then free it later. But how do you know when it's safe to free it? If you FORGET everything which follows, fine, but then why bother with dynamic memory? You can implement a poor man's memory reference counter by sweeping colon defs, but what about ['] constructs inside CODE words? Or references in an array? It feels like a losing battle to me. So I guess you'd have to look towards Factor. I can't tell if it does exactly what you want, but at least it has characteristics which make it a reasonable starting point. OTOH, if you have a system which can boot in < 0.10 seconds, and metacompile itself in less than 10 seconds, you might be better off to not worry about it. When you want to change the system, just update the source, build, then boot. My own experience with ForthOS is that this approach works quite well. -- Andy Valencia Home page: http://www.vsta.org/andy/ To contact me: http://www.vsta.org/contact/andy.html
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-10 21:56 +0100
Re: Memory management "Elizabeth D. Rather" <erather@forth.com> - 2012-04-10 10:18 -1000
Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-10 22:43 +0100
Re: Memory management "Elizabeth D. Rather" <erather@forth.com> - 2012-04-10 11:38 -1000
Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 10:33 +0100
Re: Memory management Paul Rubin <no.email@nospam.invalid> - 2012-04-11 02:35 -0700
Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 12:20 +0100
Re: Memory management Paul Rubin <no.email@nospam.invalid> - 2012-04-11 08:41 -0700
Re: Memory management David Thompson <dave.thompson2@verizon.net> - 2012-05-13 00:08 -0400
PDP-11 [Was: Memory management] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-13 09:18 -0500
Re: PDP-11 Paul Rubin <no.email@nospam.invalid> - 2012-05-14 01:09 -0700
Re: PDP-11 Paul Rubin <no.email@nospam.invalid> - 2012-05-14 01:19 -0700
Re: PDP-11 [Was: Memory management] Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-13 07:46 -0700
Re: PDP-11 [Was: Memory management] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-15 03:27 -0500
Re: PDP-11 [Was: Memory management] Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-15 11:30 +0000
Re: PDP-11 [Was: Memory management] Stan Barr <plan.b@dsl.pipex.com> - 2012-05-15 15:21 +0000
Re: Memory management Nomen Nescio <nobody@dizum.com> - 2012-04-11 21:35 +0200
Re: Memory management BruceMcF <agila61@netscape.net> - 2012-04-10 14:59 -0700
Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 10:39 +0100
Re: Memory management stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-11 09:53 +0000
Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 12:15 +0100
Re: Memory management stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-11 10:59 +0000
Re: Memory management "Elizabeth D. Rather" <erather@forth.com> - 2012-04-11 07:44 -1000
Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 20:50 +0100
Re: Memory management Paul Rubin <no.email@nospam.invalid> - 2012-04-11 11:54 -0700
Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 21:03 +0100
Re: Memory management vandys@vsta.org - 2012-04-11 19:09 +0000
Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 21:48 +0100
Re: Memory management Jecel <jecel@merlintec.com> - 2012-05-15 10:04 -0700
Re: Memory management vandys@vsta.org - 2012-05-15 17:29 +0000
Re: Memory management "A. K." <akk@nospam.org> - 2012-05-15 20:41 +0200
Re: Memory management BruceMcF <agila61@netscape.net> - 2012-04-11 12:33 -0700
Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 21:53 +0100
Re: Memory management BruceMcF <agila61@netscape.net> - 2012-04-11 13:43 -0700
Re: Memory management Tarkin <tarkin000@gmail.com> - 2012-05-13 21:20 -0700
Re: Memory management BruceMcF <agila61@netscape.net> - 2012-04-11 04:51 -0700
csiph-web