Per-generation lists of weak pointers

[Simon Marlow]

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