Per-generation lists of weak pointers

Edward Z. Yang ezyang at MIT.EDU
Mon Mar 11 23:00:43 CET 2013


Aha! That's right. It's possible, then, that foreign pointers need to
be reworked a bit, since they are relying on a weak pointer invariant
that they really shouldn't be relying on.  I think Simon Marlow would
have better guidance here.

Edward

Excerpts from Akio Takano's message of Mon Mar 11 05:15:23 -0700 2013:
> Hi Edward,
> 
> Thank you for your reply!
> 
> On Mon, Mar 11, 2013 at 8:17 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> > I was under the impression that foreign pointers finalizers were only
> > ordered with respect to multiple finalizers on a single object.  So if
> > you can show your implementation preserves same-object ordering, that
> > should be sufficient. (Nota bene: I haven't CR'd your code.)
> 
> Yes I understand that. However my understanding is that
> addForeignPtrFinalizer creates a fresh WEAK object with just one
> finalizer. So in order to maintain the same-object ordering of C
> finalizers, I still somehow need to deal with ordering between
> multiple WEAK objects.
> 
> >
> > Edward
> >
> > Excerpts from Akio Takano's message of Mon Mar 11 03:17:48 -0700 2013:
> >> 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/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?
> >>
> >> Thank you in advance,
> >>
> >> Takano Akio
> >>



More information about the ghc-devs mailing list