Greetings! Robert Boyer <[EMAIL PROTECTED]> writes:
> > BTW are we done on the after gbc hook? > > Yes, as far as I can tell. Thanks very much. > > I have mostly given up on the big-array with forged conses to hash consing > approach because I realized that I was simply stupid. GCL's GC does not > trace pointers from the stack into fixnum arrays, and quite reasonably so. > That was why some things were not getting marked. > > Yesterday, we tried a new hack of putting the big hons array on the stack, > using stack conses, and that worked remarkably well. Even with a make-list > 100000000! An advantage of that is that it is putting the honses above the > 2gb mark, leaving space below for other Lisp objects! Alas, this approach > suffers from the fact that no one is gc'ing the honses automatically, so we > have to periodically wipe them all out, as we were doing doing with the > older, strictly ANSI-conforming (no si::nani or si::address), approach to > hons. > Wow, so I guess you must be providing your own toplevel to avoid popping the stack above your hons allocation. Great! > I'm still happily using the *after-gbc-hook* hack to implement a sort of > "weak alist", that maps conses to possibly big hash tables. If the GC marks > the conses as free, I can let the hash tables go. > Is this solid enough that I can now omit the older calling pattern in the alloc functions now commented out? Have you encountered any other anomalies since that recursive GBC fix? Take care, > Thanks so very much, > > Bob > > P. S. I'll check out the make-list initialization fix right now. > > > > -- 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
