[Gcl-devel] Re: Sigh

[Camm Maguire]

Greetings!

Robert Boyer <address@hidden> writes:

> I just tried out Camm's latest 2.7.0 and it seemed to work fine as far as
> calling *after-gbc-hook* after every gc and (everything else Common Lisp).
> However, it bombed as follows, and I think that the truth is that my fooling
> around with allocating conses/honses on a static page is a classic example of
> my trying to do something way over my head.  This "stack overflow" error
> below is undoubtedly (said with grave doubts) just yet one more example of
> one of our honses that got zeroed out by our *after-gbc-hook* when it
> shouldn't have been because it didn't get marked by the garbage collector
> when we thought it "should" have been.  Because I am really just guessing
> about when things get marked, having not read and understood the gc code, not
> even understanding C, and not being smart about using GDB, and not even being
> able to build a large static GCL WITH enable-debug.  Dumb!  (Fun, though.)
> 
> As for "weak" objects, I'm suspect that Camm is pointing us in a good
> direction, though I'm not sure I understand the idea "weak" very well yet.
> (Still dumb.)  However, the beauty of "our" having total control over the
> placement of new honses in "our giant static fake cons area" is that we
> overlay a hash table right on top of the hons space, and thus allocating a
> hons seems extremely efficient: to do a "hons" we take some hash of the car
> and some hash of the cdr (both very fast -- just based upon addresses --
> which we can do reliably because these are real honses, so respect
> equality=eq), and combine the hashes to form a new hash (just a couple of
> adds and multiplies) and then look right where the hons "ought" to be, and if
> it is not there we create it there, or nearby, so we can find it very fast
> the next time we do the same hons call.  This makes hons really fast.  I may
> have missed it, but I don't think that Camm's "weak" objects gives us that
> degree of control over "where" the new hons will be placed, nor at such very
> low overhead in terms of space used per hons.  Of course, a counter point is
> that we have hogged one hell of a giant static space for honses right at the
> start for our giant hash-table-cons-static-space.
> 

You are right IMHO that a GCL-supported weak hash table implementation
will likely be somewhat slower than the design you have now.  This is
mostly becuase you'd need an extra word per hons to store the address
of the real cons in the hash table, and of course you would need to
traverse these pointers when doing any operations on the hash table.
The only advantages may be that is is somewhat cleaner/perhaps more
robust, and avoids the gc marking penalty on your huge static array.
If you ever decide you need this and have an immediate testbed for it,
I might be able to find some time to put in some simple weak hash
table support.  If there is no need, of course, limited time is best
spent elsewhere.

Take care,

> Camm, thanks so much!
> 
> Bob
> 
> Random testing output leading to the error (for Warren):
> 
>    Trying Rdp_actinobateria_All...
> 
>    Reading 
> /projects/hvg/compBio/data/trees/longer/compressed-files/Rdp_actinobateria_All.bhz.
>    [GC for 100000 CONS pages..(T=155).GC finished]
>    ?
>    At HUT flush.
>    Done HUT flush.
>    Raw Lisp Break.
>    Error in HEAD-LIST-TOP [or a callee]: Control stack overflow.
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah