Greetings! Robert Boyer <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
