<div dir="ltr">Thank you very much for your help, I just updated the patches on the ticket.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 21, 2013 at 10:50 AM, Edward Z. Yang <span dir="ltr"><<a href="mailto:ezyang@cs.stanford.edu" target="_blank">ezyang@cs.stanford.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In your ticket, you mention this patch introduces a race condition. One<br>
possible fix is to have addCFinalizerToWeak# check if the pointer is already<br>
dead, and just run the finalizer immediately if it is. I think this<br>
preserves the semantics, but this needs to be checked closely.<br>
<br>
Edward<br>
<br>
Excerpts from Akio Takano's message of Fri Apr 19 02:58:<a href="tel:50%20-0700%202013" value="+15007002013">50 -0700 2013</a>:<br>
<div class="im">> I removed the invariant by adding a new primop, addCFinalizerToWeak#. I<br>
> opened a ticket for the issue.<br>
><br>
> <a href="http://hackage.haskell.org/trac/ghc/ticket/7847" target="_blank">http://hackage.haskell.org/trac/ghc/ticket/7847</a><br>
><br>
> - Akio<br>
><br>
> On Thu, Mar 21, 2013 at 2:40 PM, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br>
><br>
> > On 11/03/13 03:17, Akio Takano wrote:<br>
> ><br>
> >> Hi,<br>
> >><br>
> >> I'm working on implementing per-generation lists of weak pointers to<br>
> >> speed up garbage collection in programs that allocate a lot of weak<br>
> >> pointers. I have a patch [1] that validates and gives a 3x speed up on<br>
> >> a benchmark. However I'd like to ask for some advise before finishing<br>
> >> and submitting the patch.<br>
> >><br>
</div>> >> [1] <a href="https://github.com/takano-**akio/ghc/commit/**" target="_blank">https://github.com/takano-**akio/ghc/commit/**</a><br>
> >> c7345c68eaa1e7f9572e693b5e352e**386df7d680<<a href="https://github.com/takano-akio/ghc/commit/c7345c68eaa1e7f9572e693b5e352e386df7d680" target="_blank">https://github.com/takano-akio/ghc/commit/c7345c68eaa1e7f9572e693b5e352e386df7d680</a>><br>
<div class="im">> >><br>
> >> The problem is that since my patch splits the weak pointer list<br>
> >> between generations, it no longer maintains the right order of weak<br>
> >> pointers. This could cause finalizers added with<br>
> >> addForeignPtrFinalizer to run in the wrong order.<br>
> >><br>
> >> I can think of one way to fix it; to make sure that when a WEAK object<br>
> >> gets promoted, it is always added to the front of the new list. So my<br>
> >> questions are:<br>
> >><br>
> >> - Would it be a correct fix?<br>
> >> - If so, is it an acceptable fix? For example, is it too fragile a<br>
> >> reasoning to rely on?<br>
> >><br>
> ><br>
> > I don't like the way that we rely on the ordering of the weak pointer list<br>
> > right now. I think this invariant arose accidentally when the support for<br>
> > C finalizers was added. It was wrong for some time, see:<br>
> ><br>
</div>> > <a href="http://hackage.haskell.org/**trac/ghc/ticket/7160" target="_blank">http://hackage.haskell.org/**trac/ghc/ticket/7160</a><<a href="http://hackage.haskell.org/trac/ghc/ticket/7160" target="_blank">http://hackage.haskell.org/trac/ghc/ticket/7160</a>><br>
<div class="HOEnZb"><div class="h5">> ><br>
> > and as per my comments in that commit log, I think we should do it<br>
> > differently. I don't know how hard that would be though.<br>
> ><br>
> > Incidentally, I implemented per-generation weak pointers in the local-gc<br>
> > branch, but didn't get around to porting it back over into the mainline (I<br>
> > still have a ToDo for that). My version probably has the ordering bug, but<br>
> > you could always look at the branch to see how my approach compares to<br>
> > yours.<br>
> ><br>
> > Cheers,<br>
> > Simon<br>
> ><br>
> ><br>
</div></div></blockquote></div><br></div>