# Re: [stack] Digest Number 27

## Mark van Gulik — 2000-05-31 14:45:24

    "Samuel A. Falvo II" <kc5tja@...> said:

     >

    > On Tue, 30 May 2000, Mark van Gulik wrote:

    >

    >> I can understand *implementing* another language in Forth, but embedding it

    >> seems kind of awkward.  GC in Forth is a big surprise to me.  In Smalltalk I

    >

    > From the point of view of Forth, there is no difference between embedding

    > and implementing, especially since to embed you must first implement.

     Yes, to embed you must first implement.  But just because a Smalltalk VM is

    implemented in assembly language doesn't mean it's *embedded* in it.  That

    would imply that new directives were added to the assembler to support the

    Smalltalk syntax, etc.  Maybe we disagree on the meaning of "embed".

     >> bugs in Java, I don't know how to corrupt memory with it at all.  C++ with

    >> GC, on the other hand, is trivial to corrupt.  Simply convert a pointer to

    >> integer, xor it with 0x55555555, store it somewhere, then later decode and

    >> try to use it.  Even with a non-moving collector, this will corrupt memory.

    >

    > This requires more coding time than just using a pointer directly; it's

    > not economical to pull such tricks.  However...

     Yes, but have you seen the doubly-linked list implementation that only uses

    one pointer per node?  The forward and backward pointers are xored together.

    When iterating (forward or backward), you must keep track of two consecutive

    nodes.  A simple xor will decode the next neighbour of these two in either

    the forward or backward direction.  An interesting technique, *impossible*

    to match the space efficiency of in a (falsely) "conservatively" garbage

    collected environment.  Of course you could use an array of nodes and use

    half-word indices into this array to implement linkages, but that's not the

    point.

     >> Many C++ compilers will do certain kinds of optimizations that are

    >> incompatible with GC (the main example being pre-adding the address of the

    >> start of an array and a constant offset that puts the address out of range

    >> of the array, even though all uses of it would offset it back into range).

    >

    > ...this is a very good point to keep in mind and is a much more valid

    > concern.

     I agree that this one is more likely to be encountered.

     >> I'm sure Forth has better control over these sorts of incompatible

    >> optimizations, but GC?  I'm skeptical of how.  I could see it might be

    >

    > Conservative GC, the same used in C and C++ systems.

     Please show me a proof (hand waving is allowed) that any Forth program which

    doesn't crash without GC still will not crash when GC is present.  Then I

    will consider calling the garbage collector "conservative".  Without that I

    will call it "guessing".

    Whoops, I'm in a rush right now.  More later...

## Samuel A. Falvo II — 2000-05-31 17:25:50

    On Wed, 31 May 2000, Mark van Gulik wrote:

     > Please show me a proof (hand waving is allowed) that any Forth program which

    > doesn't crash without GC still will not crash when GC is present.  Then I

    > will consider calling the garbage collector "conservative".  Without that I

    > will call it "guessing".

     The problems you cited with a CGC are problems which must be *explicitly

    coded for*, so it is NOT my responsibility to show you proof of any kind,

    any more than it is for me to show you proof of my identification.  As

    I've indicated more than once before, if you want more information on

    Forth-specific implementations of things, comp.lang.forth is the place to

    be.

    Furthermore, the type of GC "conservative" describes is very well

    understood in the computer science and engineering worlds; *don't* just

    arbitrarily re-define the meaning of certain words, or even re-label a

    well known design practice; it gives you a very stuck-up image and *will*

    cause major communications problems with others.

    If you don't like my use of the term "conservative", well, too damned bad.

    Deal with it.  It's what everyone else out in the real world uses, so

    that's what I'm going to use.  We can't change history, so let's just put

    it behind us, and move on.