Re: Guile 1.8.9 release

[Han-Wen Nienhuys <hanwenn@gmail.com>]

On Wed, Feb 10, 2021 at 11:18 PM Thien-Thi Nguyen <ttn@gnuvola.org> wrote:
>
>
> () Han-Wen Nienhuys <hanwenn@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 - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen