Per-generation lists of weak pointers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Per-generation lists of weak pointers

Edward Z. Yang
In your ticket, you mention this patch introduces a race condition.  One
possible fix is to have addCFinalizerToWeak# check if the pointer is already
dead, and just run the finalizer immediately if it is.  I think this
preserves the semantics, but this needs to be checked closely.

Edward

Excerpts from Akio Takano's message of Fri Apr 19 02:58:50 -0700 2013:

> I removed the invariant by adding a new primop, addCFinalizerToWeak#. I
> opened a ticket for the issue.
>
> http://hackage.haskell.org/trac/ghc/ticket/7847
>
> - Akio
>
> On Thu, Mar 21, 2013 at 2:40 PM, Simon Marlow <marlowsd at gmail.com> wrote:
>
> > On 11/03/13 03:17, Akio Takano wrote:
> >
> >> Hi,
> >>
> >> I'm working on implementing per-generation lists of weak pointers to
> >> speed up garbage collection in programs that allocate a lot of weak
> >> pointers. I have a patch [1] that validates and gives a 3x speed up on
> >> a benchmark. However I'd like to ask for some advise before finishing
> >> and submitting the patch.
> >>
> >> [1] https://github.com/takano-**akio/ghc/commit/**
> >> c7345c68eaa1e7f9572e693b5e352e**386df7d680<https://github.com/takano-akio/ghc/commit/c7345c68eaa1e7f9572e693b5e352e386df7d680>
> >>
> >> The problem is that since my patch splits the weak pointer list
> >> between generations, it no longer maintains the right order of weak
> >> pointers. This could cause finalizers added with
> >> addForeignPtrFinalizer to run in the wrong order.
> >>
> >> I can think of one way to fix it; to make sure that when a WEAK object
> >> gets promoted, it is always added to the front of the new list. So my
> >> questions are:
> >>
> >> - Would it be a correct fix?
> >> - If so, is it an acceptable fix? For example, is it too fragile a
> >> reasoning to rely on?
> >>
> >
> > I don't like the way that we rely on the ordering of the weak pointer list
> > right now.  I think this invariant arose accidentally when the support for
> > C finalizers was added.  It was wrong for some time, see:
> >
> > http://hackage.haskell.org/**trac/ghc/ticket/7160<http://hackage.haskell.org/trac/ghc/ticket/7160>
> >
> > and as per my comments in that commit log, I think we should do it
> > differently.  I don't know how hard that would be though.
> >
> > Incidentally, I implemented per-generation weak pointers in the local-gc
> > branch, but didn't get around to porting it back over into the mainline (I
> > still have a ToDo for that).  My version probably has the ordering bug, but
> > you could always look at the branch to see how my approach compares to
> > yours.
> >
> > Cheers,
> >         Simon
> >
> >