On Wed, Feb 10, 2021 at 11:18 PM Thien-Thi Nguyen <t...@gnuvola.org> wrote: > > > () Han-Wen Nienhuys <hanw...@gmail.com> > () Tue, 9 Feb 2021 09:59:07 +0100 > > > Thanks. It turns out my previous fix introduced ABI > > breakage, so I reworked it to not change function > > signatures or struct sizes. It's also split up in more > > parts, so it becomes easier to understand. Please see > > here: [...] > > Any news here? Can I do anything to get this fix in? > > IIUC, the second iteration achieves the same goals as the first > one (i.e., reducing unnecessary allocation by refining the heap > monitoring machinery). Is that correct? (What am i missing?)
the first iteration broke ABI compatibility. The second patch doesn't > > I would be happy to commit the second patch, if you could refine > it to add the extensive explanation of the first. (You could > even mention the first approach, as an interesting but misguided > dead end.) That way, we have a full record. Maybe this wasn't clear, but the second patch is actually a sequence of patches, and in aggregate they have more detailed explanation of what is going on. The following are cosmetic changes. While they don't have to be merged, per se, the formatting fixes are the basis of the bugfix changes: 701f6e2cae88883dfc1e280711345fb5a75b0aae gc: cleanup DEBUGINFO printfs. ce503b481e7486a7fb5152d3075c2d475fd33e06 gc: fix formatting inconsistencies 925edffc2d4efd19333582ca588e0aebb1c7adf8 gc-segment: clarify comments on segment initialization these are the real bug fixes: 2511e1fa97558e1d0f0620489cdd7550e7d77195 gc: reinterpret scm_gc_cells_collected as garbage counter 594783b15b00133d73aed00bb7f3304a56725497 gc: use normal sweep for pre-mark sweep the following are minor follow-on cleanups: 923c41cb94462140fa07120632f5736680a0c76e gc: calculate min_yield statelessly e2d04fdd4d8a3d9cebd0d9289c5b8f9528e47d34 gc: simplify statistic keeping > I would be extremely happy to commit a test along w/ the change, > if we can figure that out. But it's not critical (we can do it > later). > > Re testing, i don't know how to go about setting up a test to > avoid regressions. (IIUC, this is a performance-related change > and not a functionality-related one.) Any ideas? I can add a test, but it requires adding several fields to the (gc-stats) output, which might surprise callers not expecting them. Also, as it is a performance test, it is hard to construct a test that always works. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen