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/
