Andy Wingo <wi...@pobox.com> skribis: > 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.
Yes, right. >> 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. Right. I think we cannot remove them yet, but we should do what it takes so users rely less and less on them. >> 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. Since (1) is difficult to fix, and since mark procedures have other problems as you explain, I was inclined to address the Lily problem via (4). > 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_. Point taken. BDW-GC makes them useless in most cases anyway. > 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. I think so. I admit I’m more concerned with the immediate problems of LilyPond though. ;-) > 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. Agreed! Commit d9a4a1c uses very clear wording to recommend against mark procedures, which is the right thing IMO; commit 56273de from 2009 already hinted in that direction, though not as prominently. Since I missed the original discussion between you and Mark, I might well be completely off, in which case I apologize. Thanks, Ludo’.
