[CM] setting heap size preemptively at startup?

bil at ccrma.Stanford.EDU bil at ccrma.Stanford.EDU
Fri Sep 10 06:32:28 PDT 2021


Elijah is correct, but I/m worried there might be some ambiguity.  The 
s7_cells (the
s7 objects) are allocated permanently (except s7_free frees them), and 
the heap itself
is an array of pointers to those objects.  The objects themselves are 
not copied or
moved by the GC.  In normal use the GC frees 90% or so of the heap, and 
puts the
pointers to the newly free objects in the heap free list, clearing the 
type of the
freed object.  This clear requires access to each free object, thus 
forcing the GC
to bring it into memory -- I think that is where the cache misses are.  
The GC mark
process appears to take only a small part of the time.

When the heap has to grow, realloc makes the new heap array of pointers, 
so the
old pointers might be copied, but most the heap resize time is spent 
allocating the
new permanent block of s7_cells, then placing pointers to them into the 
heap and
free_heap arrays.

You can see what the GC is doing via (set! (*s7* 'gc-stats) 1).  I don't 
think
there's any problem with starting with a big heap (some of my timing 
tests do
this because the GC is not of interest in that context), but the GC 
process when
called will probably be slower.





More information about the Cmdist mailing list