[Gcl-devel] Re: after gbc hook

[Camm Maguire]

Greetings!

Robert Boyer <address@hidden> writes:

> I'm having a lot better luck today since I realized that now even si::gbc
> calls *after-gbc-hook*!
> 

Indeed, this should now be the only place.

> I have seen at least one case where a relocatable gc does not result in a
> call to *after-gbc-hook*.  Below is a little visual evidence of it.  Question
> mark is supposed to come out at the start of the call of our *after-gbc-hook*
> function.  I cannot seem to reproduce this easily enough to send you a decent
> bug report yet.
> 
>   [GC for 4510 RELOCATABLE-BLOCKS pages..(T=69).GC finished]
>   [GC for 23662 RELOCATABLE-BLOCKS pages..(T=66).GC finished]
>   ?

It is possible, however, that GBC be called recursively in normal
practice.  This is almost always via its call to alloc_page when
reserving space for the mark table in the relocatable section of
memory.  While gcl never directly modifies data stored in contiguous
pages during the mark phase, it does mark reachable data in this
auxiliary table.  Unused data on these pages is then swept by
inserting a linked list structure at the beginning of the area
consisting of a pointer to the next structure, and an integer size of
the amount that is free.  So your static fixnum array, while very fast
in its avoidance of the extra memory indirection incurred in an
ordinary array of cons pointers, and in its assurance of great data
locality, and in its parsimonious use of memory, does incur this
marking performance penalty at each gc.  As long as the area size and
location is not changed too much, which in your case would appear to
be not at all, this penalty is likewise well worth it.  Otherwise,
manipulating the allocation and deallocation of contiguous pages is
the lowest memory item we have in GCL.  Try
(si::SET-GMP-ALLOCATE-RELOCATABLE nil) and examine bignum performance,
for example.

When in a sub GBC, you should see (T=...), so this does not exactly
fit your example above.  In any case, I can't see where a recursive
call would hurt you -- the sub-call calls *after-gbc-hook* which
should leave memory in a consistent state for the marking phase of the
parent call.  GBC cannot return without calling the hook, to my
understanding. 

Have you tried not collecting anything, and letting the area fill up
as long as possible?  Does this work?  Also please know that only the
honses reachable from the 'root set' will be marked -- i.e the lisp
stacks, the C stack, explicitly entered mark origins, and internal and
external symbols of known packages.  If the mark tree would start at a
hons (on a contiguous page), said tree will remain unmarked.

Take care,

> 
> Thanks,
> 
> Bob
> 
> 
> 

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