I've been doing some GC work as well, and I have a possible feature that i'm thinking about implementing that i'd like to run by you guys
What if there was a (*s7* 'gc-hook) that ran before the gc routine got run. From that hook, it should be possible to 1) prevent the gc from running if it's a critical time 2) schedule the gc to run when the system is less busy I'm using s7 in a video rendering app, and i'd like to only have the gc run in-between frames, to keep my frame pacing as close to constant as possible Let me know what you guys think -Woody On Thu, 2021-09-09 at 21:52 -0700, Iain Duncan wrote: > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you recognize the sender. > > 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! > iain > > On Thu, Sep 9, 2021 at 9:42 PM Elijah Stone <[email protected]> > 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 > > [email protected] > > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > > > > _______________________________________________ > Cmdist mailing list > [email protected] > https://cm-mail.stanford.edu/mailman/listinfo/cmdist _______________________________________________ Cmdist mailing list [email protected] https://cm-mail.stanford.edu/mailman/listinfo/cmdist
