Re: BDW-GC-Guile incompatibilities

[ludo@gnu.org (Ludovic Courtès)]

Hi Neil,

Neil Jerram <neil@ossau.uklinux.net> writes:

> Sorry for my delay in following up here...

Same for me!

>>>>  1. The lack of `gc-live-object-stats'.

> I was actually thinking of decrementing an object type counter when an
> object is collected - and having looked more at the docs I see that
> that would mean using GC_register_finalizer ().  However I also see
> from [1] that that (having most SCM objects being finalizable) would
> be very bad for the effectiveness of the GC - because of the point
> that in a chain of finalizable objects, only one object (the head) is
> finalized in each collection.

Yes, finalization should be used sparsely.

> Ultimately I think `gc-live-object-stats' can be sacrificed if need
> be.  If there are specific application needs for part of the
> information that it provides, I would guess that they are actually for
> specific object types only and could be met by using a guardian.

Yes, that's right.  It's just less convenient, especially when searching
for a leak of unknown origin.

>>>>  3. Different behavior of weak hash tables, see
>>>>     http://lists.gnu.org/archive/html/guile-devel/2008-11/msg00015.html .
>>>>     This can be fixed, but I'm unclear whether it's worth it (comments
>>>>     welcome!).

> Yes, but at least it is a change that we can document, and we can
> precisely advise application authors what they need to do if they see
> this problem.

Right, this may be acceptable.

> Thanks for the detailed description.  But this case could also be solved
> by making scm_stand_in_procs doubly weak, can't it?

Yes (there are doubly-weak tests in `weaks.test').

> (Also, I wonder if it could be solved by getting rid of the stand-in
> thing.  Why does eval-closure need 2 references to module?  Sounds
> like it might be a case of design rot.)

Indeed, there may be room for improvement here.  :-)

> Finally, another concern from [1] is "Cycles involving one or more
> finalizable objects are never finalized."  Given that, can our
> guardians still work?  You mentioned in another email about "possible
> guardian glitches", is this what you had in mind?

What I had in mind is the various tests in `guardians.test' that end up
being "unresolved" (see, e.g.,
http://autobuild.josefsson.org/guile/log-200902271203718687000.txt).  On
my machine I was actually seeing more of them.

The issue is that these tests never fail, they just throw `unresolved'
at worst.  This is due to the fact that we use a conservative GC so if
an object remains alive, it can be due to the fact that a stale
reference to the object is visible on the stack, for instance.

I investigated these `unresolved' test cases, which led to this patch:

  http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=6a7489ace3f07a8d190110cd1244963526c65729

In most cases, the tests can be made to succeed instead of being
unresolved by changing the code in a way that increases chances that
no references to the object we expect to die are left on the stack.

However, the "g2-garbage saved" is clearly a bug, as explained in the
commit above.  OTOH, this use case is probably not representative of any
real-world application, so I wouldn't worry about it.

Besides, it would be possible for an application to create a cycle of
guardians, which would prevent them from being GC'd, as you noted.
Similarly, an application could create mutually referenced SMOBs, both
of which have a `free ()' procedure; these could not be GC'd either.
But again, that sounds rather unrealistic IMO.  What do you think?

Thanks,
Ludo'.