Why I want Haskell finalizers
alastair at reid-consulting-uk.ltd.uk
Wed Oct 16 13:06:57 EDT 2002
>> So what you want is for the Java GC to call hs_freeStablePtr on all
>> the Haskell objects that just died?
> No, that's only a partial (and indeed very incomplete) solution. It
> relies on the Java GC knowing that that particular reference to the
> Haskell StablePtr is the only one that matters, and vice-versa for
> the Haskell GC.
So you want StablePtrs to contain a reference count, a new function
to increment the count and for freeStablePtr to decrement the count?
We toyed with designs like that but always found other ways to achieve
the same goal - but it's easy enough to do.
A variant is for newStablePtr to look for an existing StablePtr to the
same thing. We avoided this design because of the semantic issues in
testing Haskell pointers for equality but mostly to avoid imposing a
lookup cost that we'd rarely benefit from.
> If you want any slightly more complicated logic
> (such as if Java has multiple references to the same StablePtr, or
> if you want to detect if this particular freeStablePtr might free a
> circular data structure) you'll have to write it in C.
As you know, I'm not against writing finalizers in C :-)
Seriously though, I think detecting circular data structures requires
more than just a cool C (or Haskell) library on the Haskell-Java
interface. I think it requires at least one but probably both GCs to
provide hooks so that the GCs can get some sense of what Haskell roots
are keeping what Java roots alive and vice-versa. (Every time I think
about this problem, the word 'epoch' comes to mind...)
More information about the FFI