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


Groups > comp.lang.forth > #11163

Re: Memory management

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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