Re: Grow heap aggressively during music interpretation (issue 561390043 by address@hidden)

[dak]

On 2020/02/09 10:08:20, hanwenn wrote:

> A way around that is to change all instances of vectors holding SCM
values to a
> new 
> gc_vector type that has a custom allocator.  That will be significant
work, but
> probably
> desirable in the long term.

I'd recommend a two-pronged approach for now, lobbying for changes in
the bdwgc that make it suitable for dealing with a larger ratio of
finalisers and, while angling for going to vectors with their own
allocators, sticking with code that can do either.  That way bdwgc will
eventually become better for our current work load and if it leads to
faster or more resource-efficient behavior to rely on finalisers for
marking rather than treating everything as conservative pointers, we
still have the option to return to what we are doing, or pick a mixed
strategy (there likely would be no point in ever marking SCM arrays via
mark hooks if we can just allocate them in mark-everything memory areas:
at least that part should never be contentious, and STL structures of
SCM are the most irksome with regard to not causing trouble before
creation or after destruction).

https://codereview.appspot.com/561390043/