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

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