Re: Mark procedures

Andy Wingo skribis: > Picking up an old thread > > On Thu 05 Nov 2015 14:11, Andy Wingo writes: > >> (1) A bug related to SMOB finalization and marking that affects >> LilyPond >> >> For (1) it seems to me that we just have a bug. A SMOB mark function >> was called on an object after

Re: Mark procedures

Picking up an old thread On Thu 05 Nov 2015 14:11, Andy Wingo writes: > (1) A bug related to SMOB finalization and marking that affects > LilyPond > > 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

Re: Mark procedures and LilyPond

> On 6 Nov 2015, at 13:32, Mark H Weaver wrote: >> 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. > > Unfortunately, I doubt this will be sufficient for LilyPond

Re: Mark procedures and LilyPond

>____ > Objects in | | | | > GC-managed | SMOB 1 | | SMOB 2 | > heap |__| |__| > | ^

Re: Mark procedures and LilyPond

Mark H Weaver skribis: > Unfortunately, I doubt this will be sufficient for LilyPond. The small > example case in , which is apparently > representative of how things are typically done in LilyPond, has > structures like this: > >__

Re: Mark procedures and LilyPond

Andy Wingo writes: > On Thu 05 Nov 2015 11:29, l...@gnu.org (Ludovic Courtès) writes: > >> What we need above all is to address LilyPond’s use case. I proposed a >> solution at but >> never understood whether/why it was considered unfit. >

Re: Mark procedures, LilyPond, and backward compatibility

Hi :) I appreciate what you say. I do think that we are mixing topics a bit. Regarding the future applicability of the foreign object API to precise and moving GC -- this can be added. I have worked with precise and moving GC systems. During the time that I hacked on SpiderMonkey, it moved from

Re: Mark procedures

Andy Wingo 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], a

Re: Mark procedures

On Thu 05 Nov 2015 11:29, l...@gnu.org (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

Re: Mark procedures

Hello! I think we all agree that mark procedures suck in many ways, so that’s not the problem. When I ported the old Guile to BDW-GC, I kept them mostly so existing code that uses SMOB can still work as expected. Of course, 90% of the time you could just remove them and things would work, but if

Re: Mark procedures, LilyPond, and backward compatibility

Hi Andy, Thanks for the detailed analysis of the problems with mark procedures. Andy Wingo writes: > At the end of our IRC conversation yesterday you put the burden on me to > argue against mark procedures, which was fair, but at this point I think > we would need good arguments for keeping them

Re: Mark procedures

Good post! I first like to second the need for our own gc. Regarding mark procedures. I prefer that we collect the use cases and make sure that the framework can handle them in a robust and effective way. I don't like to write mark procedures at all and your fixes seam to address quite a lot of m