Re: Mark procedures

[Andy Wingo]

On Thu 05 Nov 2015 11:29, address@hidden (Ludovic Courtès) writes:

> I think we all agree that mark procedures suck in many ways, so that’s
> not the problem.

:)

Some of the points I made have not been made before, AFAIK.  The point
about marking occuring concurrently with the mutator even in the absence
of threads, for example.

> I agree with you that we must keep recommending against using [mark
> procedures], and that remaining uses should probably be questioned; I
> think we can’t “just” remove them though.

I am not sure, to be honest.  I am not proposing "just" removing them.
However if we can remove them, then we *certainly* should do so -- we
should plan our API in that way.

> What we need above all is to address LilyPond’s use case.  I proposed a
> solution at <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19883#23> but
> never understood whether/why it was considered unfit.

I agree with you that the patch there looks reasonable to me too, though
AFAIU the original code should work just fine too.

There area few things at play.

 (1) A bug related to SMOB finalization and marking that affects
     LilyPond

 (2) The utility of mark procedures in general

 (3) The suitability of mark procedures for future uses

 (4) Whether we can get by without mark procedures, and if so, how.

For (1) it seems to me that we just have a bug.  A SMOB mark function
was called on an object after the finalizer.  ****Note**** that having
the finalizer called doesn't mean that the GC object was collected -- it
just means it was collectable, perhaps in a clique of objects.
Finalization being asynchronous with marking it's possible that a clique
of objects was only half-finalized when a new mark procedure runs.  The
mark procedure saw an object on which free() was already called -- this
is possible.

We should fix Guile so to "null out" the SMOB typecode when the SMOB
finalizer is called.  If our mark procedure sees a SMOB that has already
been finalized, it just returns.

Though finalizers in general can resuscitate objects, that was never a
contract of SMOB finalizers, and I think in fact it's an anti-contract.
Unfortunately for maximum robustness we probably need to grab the alloc
lock when swapping out the typecode; too bad.  This is not the same as
marking dead objects on free lists.  An object is first finalized, then
BDW-GC removes its finalizer, then if it is collected in the next GC it
goes on a freelist.

For (2).  To me the existence of other systems with proper GC but no
mark procedures, especially JS VMs, means that mark procedures are not
_necessary_.

For (3) I hope I have successfully argued that what we need for precise
and moving collection is not the same as mark procedures.  I think Mark
would like to deal with these topics at the same time but I strongly
disagree.

Point (4) indicates to me that if we are making new abstractions that we
would like to encourage people to use in the future, we should not
encourage mark functions.  We can add some other mechanism (type
descriptors, for example).  SMOBs and their horrible mark procedures
aren't going away any time soon, of course.

Andy
-- 
http://wingolog.org/