[CM] setting heap size preemptively at startup?

Iain Duncan iainduncanlists at gmail.com
Thu Sep 9 21:52:14 PDT 2021

Thanks Elijah, that's very helpful. So this is what I'm taking away from
what you said, if you don't mind correcting me anywhere I'm wrong, that
would be lovely

- we can lock out the gc for the duration of a piece, this is reasonable
- but to do so, we should definitely establish the upper bound of the heap
size you need and pre-allocate it
- we really don't want to get this wrong, because doubling the heap part
way through will be (probably) an underrun, as everything in the old heap
gets copied to the new one
-  once the heap is big, only a reboot of the interpreter will bring it
back down again.

One thing I'm not clear on: is it necessarily a lot slower for the gc to do
a run with a large heap, even if the heap is not in use? Or is
the bottleneck the number of objects the gc goes trawling through?
I guess another way of putting that is: is there any real disadvantage to
over-allocating the heap size aside from using up RAM?

Thanks so much!

On Thu, Sep 9, 2021 at 9:42 PM Elijah Stone <elronnd at elronnd.net> wrote:

> On Thu, 9 Sep 2021, Iain Duncan wrote:
> > Is there a way to pre-emptively make the heap big from c or scheme,
> > aside from compiling in a default size?
> (set! (*s7* 'heap-size) ...)
> > So I'm wondering if it would be reasonable to give users an option to
> > trade size for speed by allocating a big hunk of memory and cleaning up
> > when it doesn't matter.
> That is very reasonable, but note that you cannot shrink the heap.
> > does a heap resize take a long time?
> It requires copying the entire heap.  Probably not something you would
> want to do in real-time.
> > Do they take progressively more time (ie does the heap double or
> > somesuch thing)
> Yes, it doubles.  (Obviously this also means you're asymptotically less
> likely to need a resize as time goes on...)
>   -E
> _______________________________________________
> Cmdist mailing list
> Cmdist at ccrma.stanford.edu
> https://cm-mail.stanford.edu/mailman/listinfo/cmdist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20210909/193b9e1d/attachment.html>

More information about the Cmdist mailing list