gmane.comp.lang.haskell.cafe

Simon Marlow | 14 Jan 13:13

HEADS UP: finalizer changes coming in GHC 6.10.2

By popular demand, GHC 6.10.2 will support finalizers that are actually 
guaranteed to run, and run promptly.  There aren't any API changes: this 
happens for finalizers created using newForeignPtr as normal.

However, there's a catch.  Previously it was possible to call back into 
Haskell from a finalizer (finalizers are C functions), by using foreign 
import "wrapper" or foreign export.  According to the FFI spec, whether 
this is allowed or not is "system dependent".  In GHC 6.10.1 and earlier it 
was allowed, but in 6.10.2 and later it is not.  The reason being that C 
finalizers are now executed directly by the GC, when the runtime is not in 
a position to handle callbacks.

You can still have fully-fledged Haskell finalizers if you want: we have 
Foreign.Concurrent.newForeignPtr for that purpose.  But those finalizers 
are not subject to the same promptness guarantees that you get with C 
finalizers - they run in a separate thread, and are not guaranteed to be 
run at program exit.

We'll make sure this is documented prominently in the 6.10.2 release notes, 
but I thought a heads-up would be a good idea right now as it turns out 
that there are existing libraries (e.g. LLVM) that will be affected.

Cheers,
	Simon

headers

Johan Tibell | 14 Jan 16:09

Re: HEADS UP: finalizer changes coming in GHC 6.10.2

On Wed, Jan 14, 2009 at 1:14 PM, Simon Marlow <marlowsd <at> gmail.com> wrote:
> By popular demand, GHC 6.10.2 will support finalizers that are actually
> guaranteed to run, and run promptly.  There aren't any API changes: this
> happens for finalizers created using newForeignPtr as normal.

Does this effect GC performance even if you don't use finalizers?

My knowledge of how finalizers affect GC performance is limited but
now and then I stumble on some Java article (e.g. [1]) that claims
that they can slow things down. That's no problem if there's no
additional cost added to code which doesn't use finalizers.

1. http://java2go.blogspot.com/2007/09/javaone-2007-performance-tips-2-finish.html

Cheers,

Johan

headers

Simon Marlow | 14 Jan 16:35

Re: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2

Johan Tibell wrote:
> On Wed, Jan 14, 2009 at 1:14 PM, Simon Marlow <marlowsd <at> gmail.com> wrote:
>> By popular demand, GHC 6.10.2 will support finalizers that are actually
>> guaranteed to run, and run promptly.  There aren't any API changes: this
>> happens for finalizers created using newForeignPtr as normal.
> 
> Does this effect GC performance even if you don't use finalizers?
> 
> My knowledge of how finalizers affect GC performance is limited but
> now and then I stumble on some Java article (e.g. [1]) that claims
> that they can slow things down. That's no problem if there's no
> additional cost added to code which doesn't use finalizers.

Yes, having lots of finalizers could affect GC performance, but that hasn't 
changed.  There are things we could do to speed it up, if it became a 
serious bottleneck - for example, we currently look at all the weak 
pointers on every GC, but we could separate them by generation like we do 
for threads.

Cheers,
	Simon

headers

Sigbjorn Finne | 14 Jan 16:26

Re: HEADS UP: finalizer changes coming in GHC 6.10.2

Thanks Simon,

great stuff; I like the introduction of these  'native code finalizers', 
they've
been sorely missed at times.

You don't say, but will there be a dynamic check to catch such re-entries?

--sigbjorn

On 1/14/2009 04:14, Simon Marlow wrote:
> By popular demand, GHC 6.10.2 will support finalizers that are 
> actually guaranteed to run, and run promptly.  There aren't any API 
> changes: this happens for finalizers created using newForeignPtr as 
> normal.
>
> However, there's a catch.  Previously it was possible to call back 
> into Haskell from a finalizer (finalizers are C functions), by using 
> foreign import "wrapper" or foreign export.  According to the FFI 
> spec, whether this is allowed or not is "system dependent".  In GHC 
> 6.10.1 and earlier it was allowed, but in 6.10.2 and later it is not.  
> The reason being that C finalizers are now executed directly by the 
> GC, when the runtime is not in a position to handle callbacks.
>
> You can still have fully-fledged Haskell finalizers if you want: we 
> have Foreign.Concurrent.newForeignPtr for that purpose.  But those 
> finalizers are not subject to the same promptness guarantees that you 
> get with C finalizers - they run in a separate thread, and are not 
> guaranteed to be run at program exit.
>

(Continue reading)

headers

Simon Marlow | 14 Jan 16:36

Re: HEADS UP: finalizer changes coming in GHC 6.10.2

Sigbjorn Finne wrote:
> Thanks Simon,
> 
> great stuff; I like the introduction of these  'native code finalizers', 
> they've
> been sorely missed at times.
> 
> You don't say, but will there be a dynamic check to catch such re-entries?

There is (now) a dynamic check, yes.

Cheers,
	Simon