[Gcl-devel] Re: sgc

[Camm Maguire]

Greetings!

Robert Boyer <address@hidden> writes:

> Thanks, Matt!  That's more solid evidence that I'm the one who is confused.
> 
> For a while a few months back, sgc seemed to be causing the Nqthm test suite
> some real problems with memory expanding way too much.  But Camm fixed that
> and I have no current evidence that sgc does any sort of harm for the Nqthm
> test suite.
> 
> There is another relevant parameter that I have been long curious but
> ignorant about.  In nqthm-1992/make/save.lisp, we do (SI::SET-HOLE-SIZE 500)
> right before turning sgc on.  I seem some remnant of that in ACL2's function
> save-acl2-in-akcl.  As best I recall it, this is just exactly following
> advice of Schelter from maybe ten years ago, or more.  Recently, reading
> through the kcl-report, I have begun to get a glimmer of what the "hole" is.
              ^^^^^^^^^^

A nice document the equivalent of which I hope we can include in GCL
at some point, as the document itself cannot be merged into GCL's
documentation per the author's directions.

> I believe it is something like the amount of space that cons and other
> structures can grow into before a big gc is forced that would cause the
> "relocatable" (e.g., string and array contents) to be shifted up to make more
> room.  Probably, with the unbelievably vast expansion of memory in the last
> 10 years, 500 is now stupidly small.  I'm not recommending anything, just
> mentioning a slight lifting of a big mantle of darkness in my understanding
> of GCL storage allocation.  Probably you're already doing something much
> smarter than a dumb 500 in ACL2 -- I see other references to HOLE in ACL2
> build code.

The default hole in GCL is 1/10 of MAXPAGES, in this case 3200 pages.
Smaller values lets one grow the heap in finer increments, perhaps
shrinking the final image somewhat.  Larger values allow quick
allocation of pages without triggering gc.  Following your decision
with *optimize-maximum-pages*, you might want a small hole for
building acl2, and then set it to something large before the final
save.  The hole is not saved to disk, but will be part of the virtual
memory size of the process (not the resident memory size, though,
which is more important).  I would have no a priori recommendations in
the absence of experimentation.  But if you leave sgc on, overrunning
the hole has an added overhead, so I can't see the rationale for
leaving the user (after final save) with a smaller hole than the gcl
default. 

Take care,

> 
> Bob
> 
> 
> 

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