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 <ezy...@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 > >> _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
