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.
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  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.
> >>  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