[Ecls-list] Was --enable-gengc ever the default?

[Juan Jose Garcia-Ripoll]

On Mon, Mar 1, 2010 at 5:42 PM, Andy Hefner <ahefner at gmail.com> wrote:
> This is something of a stupid question, but I'm failing to produce an
> answer myself through googling and searching the Git log. Has
> --enable-gengc ever been the default? If so, when and why was it
> disabled?

No, it was never the default because it is broken on several
platforms. There is also the problem, not advertised in the GC
documentation, that "gengc" --"incremental" in their language-- does
not work at all with multithreading. They do not even have it very
clear whether they can work, or they do not work, or whether the
problem is just with parallel marking, but in this case it is not
really clear when it becomes active or not.

> I'm investigating the possibility that GC pauses are now noticable in
> my app where they weren't previously (not necessarily true - it's
> possible I just didn't notice them before), and curious if it turns
> out I was using the gengc when I settled on the impression several
> months ago that GC delays weren't perceptible. On the other hand, a
> lot of variables have changed (ECL has progressed considerably, and
> I'm currently building ECL with different options and a new version of
> the GC). Lots of possibilities to explore, if this becomes a real
> problem.

You may also try and improve the existing precise garbage collector
or, if you use multithreaded applications, help in implementing
thread-local allocation -- that would really help.

If you want my opinion, performance of the garbage collector has
indeed degraded over the past months, but really without us doing
nothing towards it. I notified the developers of a discrepancy in the
performance between 32-bits and 64-bits versions, which I discussed
here also briefly (it was found to be the source of problems in bignum
operations). Seems the 32-bit version, for 1/4th of the memory,
performed 10 times more frequent garbage collections. This is
discussed in a thread at the GC mailing list and is still to be
debugged.

> While I'm bothering the list, why is "Function [foo] is global but is
> closed over some variables." worth issuing a note about? I find this
> annoying, and will shortly hack it out of my local copy.

If a function is closed over variables then the process of installing
it in the ECL lisp image is costly and the function can not be called
directly. In older versions of the compiler this closure might happen
accidentally, and the warning (actually a note) remained there to
visually inspect whether there are still problems with closure
identification. If it is too annoying or frequent in your code, then
we may consider changing it to a compiler-debug note --- but please
inspect the output and verify that indeed those closures are indeed
closures and that ECL is not misidentifying them.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com