Per-generation lists of weak pointers

[Akio Takano]

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 <marlowsd at gmail.com> 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**386df7d680<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<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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130419/c0dd0ea4/attachment.htm>