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


Groups > comp.lang.forth > #34962

Re: A stack oriented garbage collector.

From "David N. Williams" <williams@umich.edu>
Newsgroups comp.lang.forth
Subject Re: A stack oriented garbage collector.
Date 2014-12-16 09:38 -0500
Organization University of Michigan
Message-ID <m6pg4j$99p$1@dont-email.me> (permalink)
References <543e811f$0$15875$e4fe514c@dreader35.news.xs4all.nl> <m6ne35$om9$1@dont-email.me> <54901cdc$0$6895$e4fe514c@dreader36.news.xs4all.nl>

Show all headers | View raw


On 12/16/14 6:51 AM, Albert van der Horst wrote:
 > [...]
 >
 > I have gone to a FIFO buffer for strings that must be
 > recollected instead of a stack.
 > If I need a new stream, the old one is kept around, but the one
 > before that is freed.
 > For now the fifo is two deep, and it works.
 > If I use your $s> idea to move a string to ALLOCATE space and (maybe
 > move the HERE pointer back, if the string was at HERE), I can even do
 > something about the regular expression strings (in fact all
 > string-constants like "HAPPYPEPPY" ) to make them collectable:

To clarify a bit, in the case of dstrings, the $s> ("string-stack-from")
operation does not copy the string body.  The body of the stream string
being built by concatenation resides in dynamic string space, and could
trigger collection as it grows, if not prevented.  That's why a safe-s+,
which cannot trigger collection, has to be used while substring analysis
based on ( addr len) is still going on.  String constants are
"external", residing outside of string space, and not collectable.

Uh-oh!  I see a bug in my code.  The $+ operation can also trigger
collection.  A fix is to omit the safe-s+ definition and surround the
loop containing substring analysis by gc prevention:

----------
: GLOBAL  ($: old$ pattern$ replacement$ -- new$ )
(
Replace all occurrences of the pattern$ body in old$ by the replacement$
body, leaving new$.  The input old$ may be either dynamic or external.
)
   replacement$ $!
   pattern$     $!
   ($: old$) $s> ( old.s)
   $gc-off
   BEGIN
     ( prev.s) pattern$ $@ $s> s-separate
     ( after.s before.s true | prev.s false)
   WHILE
     s+ replacement$ $@ $+
   REPEAT
   ( prev.s) s+ ENDCAT ($: new$) $gc-on ;
----------

I *think* I would have caught that if I'd bothered with a dstester
suite...

 > "
 >      \ ciforth's way to add definitons to the minimum search order
 >      \ which is just a NAMESPACE called ONLY (say a wid/vocabulary)
 >      ONLY DEFINITIONS PREVIOUS \ this phrase doesn't change search order
 >      : "   " $s> ; PREFIX  IMMEDIATE
 >      DEFINITIONS \ Restore  previous situation
 > "
 > So we redefine the "-recognizer for string-denotations to make
 > strings collectable.

I like ciforth's way, and hope to eventually get into it.

 > $>s would save the allocated address in a fifo, and with each
 > allocation the last one falls off after being g.c-ed.
 >
 > In the case of GLOBAL a 4-deep fifo would cover it.
 >
 > The messiest part about it all is where something is appended
 > to a string in ALLOCATE space. Then we must do a RESIZE.
 > This can't be helped, I think.

The dynamic string space is ALLOCATE'd, but I haven't bothered with
RESIZE.  Garbage collection just throws an exception if it can't reclaim
enough room for an operation that copies into string space.

-- David

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


Thread

A stack oriented garbage collector. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-15 14:13 +0000
  Re: A stack oriented garbage collector. humptydumpty <ouatubi@gmail.com> - 2014-10-15 12:48 -0700
    Re: A stack oriented garbage collector. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-16 08:59 +0000
  Re: A stack oriented garbage collector. "David N. Williams" <williams@umich.edu> - 2014-12-15 14:51 -0500
    Re: A stack oriented garbage collector. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-16 11:51 +0000
      Re: A stack oriented garbage collector. "David N. Williams" <williams@umich.edu> - 2014-12-16 09:38 -0500
        Re: A stack oriented garbage collector. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-17 01:07 +0000

csiph-web