🚀 go-pugleaf

BACKGROUND ...

I am working on an application where experience has shown that I can
profit by assiting with the storage management.  For example, I have a
priority heap that can grow to more than a million items.  The heap is
in a separate, temporary area so that ADJUST-ARRAY is very eficient.  My
heap algorithm uses a locative, pointing to a cons of the heap array, as
the communications between itself and its user.  Thus, in a debug break,
the locative, not the pointer is printed.  When the algorithm completes,
SYS:RESET-TEMPORARY-AREA is used to return storage and the cons is set
to hold nil instead of the array.  The reason for the locative usage is
fear: If the heap array, a structure in a temporary area gets into a
dynamic window history, I believe the gc could take a fly.


MORE BACKGROUND ...

I have another structure called a node.  Nodes are the things that go in
the heap and are about a half dozen words long.  During problem solving,
more than a million nodes might be consed.  Also, I may want to examine
some of them in debug breaks.  However, after problem solving is
complete all or almost all nodes are garbage.  Because of the fear
mentioned in the above paragraph, I do not cons the nodes in a temporary
area.  Note, both the ephemeral and dynamic gc are on during processing.


QUESTIONS ...

1. Am I correct to show fear of the gc to the extent that I do?

2. Is there some kind of area that I can create for the nodes that will
   help the gc do the right thing?  I think the right thing is to keep
   nodes out of dynamic levels so that they will disappear when the gc
   finally catches up.

3. Are there good settings of the gc parameters to help the gc do the
   right thing?


Thanks in advance for any help or suggestions.  I have tried reading the
genera documentation BUT, to do experimentation to determine answers can
take weeks or months.  My hope is that your years of experience can give
me more immediate insights.

Jeff Barnett