Re: OLD_GC

[Vladimir T. <vtz...@gm...>]

I understand this and it's the right approach, imo.
Now as I re-read, my statement may sound as if I'm kind of offended -
definitely not the case :).

Related issue is the barrier to entry for newcomers. Having so many build
options and the dense codebase cause frustration to people interested to
get involved. I don't know what is the solution for this but it's
definitely a problem.

Normal users are also affected - people try something and submit bug
reports without reading http://www.clisp.org/impnotes/clisp.html#bugs and
following conversation is about 'clisp --version', build options, etc.
Probably having binary releases is the 'good enough' solution for this.



On Sat, May 27, 2017 at 10:41 PM, Bruno Haible <br...@cl...> wrote:

> Hi Vladimir,
>
> > I see you've added OLD_GC to revert to pre-MT GC. While adding MT stuff I
> > tried hard to keep everything "as is" in single thread builds.
>
> This is good, and I appreciate it. The principle is that any complex
> feature
> should have a simple substitute, so that we can isolate bugs by trying
> to reproduce them in various configurations. This is the idea behind
> ENABLE_UNICODE, NO_GENERATIONAL_GC, NO_GETTEXT, and so on.
>
> For the GC, there's not only your existing (past) changes. There's also
> new algorithm alternatives that we may implement in the future, such as
>   - a "1 page per object" model, that may be useful with valgrind,
>   - a "1 new generation per thread" structure, that would make the
>     allocation of a new object in MT lock-less in most cases,
>   - a possible parallel or incremental GC,...
> The OLD_GC is meant as a reference point, to make it easier to
> distinguish bugs due to new GC changes from bugs outside the GC.
> The DEBUG_GCSAFETY instrumentation catches a number of bugs of the
> latter category, but not all.
>
> Bruno
>
>