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.
_______________________________________________
Cmdist mailing list
[email protected]
https://cm-mail.stanford.edu/mailman/listinfo/cmdist
