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

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

I removed the invariant by adding a new primop, addCFinalizerToWeak#. I opened a ticket for the issue. http://hackage.haskell.org/trac/ghc/ticket/7847 - Akio On Thu, Mar 21, 2013 at 2:40 PM, Simon Marlow wrote:

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/** c7345c68eaa1e7f9572e693b5e352e**386df7d680https://github.com/takano-akio/ghc/commit/c7345c68eaa1e7f9572e693b5e352e386d...

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/7160http://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