RE: Why I want Haskell finalizers
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. GHC's StablePtr implementation does all this, BTW. We were considering removing it because of the overhead, though. Cheers, Simon ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Why I want Haskell finalizers
George writes: If you have Haskell talking to some other language with a garbage collector, be it Java or SML, then at a given point of the program you can in general expect to have Haskell holding stable pointers to objects referenced from their world by the other language, and vice-versa. The most obvious way of garbage-collecting these is for each language to reference the foreign objects using its own version of ForeignPtr's, which then instruct the other's RTS that the corresponding stable pointer is no longer required. So what you want is for the Java GC to call hs_freeStablePtr on all the Haskell objects that just died? That requires that the Haskell runtime system export a C function hs_freeStablePtr which fiddles around with the relevant GC data structure for stable pointers. No problem at all. Hugs has exported this function for some years now (though under a slightly different name). Similarily, you want Haskell's GC to call a function in the Java Native Interface (JNI) to release any Java objects that Haskell may have. I imagine that is straightforward. -- Alastair ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Why I want Haskell finalizers
Alastair Reid wrote: George writes: If you have Haskell talking to some other language with a garbage collector, be it Java or SML, then at a given point of the program you can in general expect to have Haskell holding stable pointers to objects referenced from their world by the other language, and vice-versa. The most obvious way of garbage-collecting these is for each language to reference the foreign objects using its own version of ForeignPtr's, which then instruct the other's RTS that the corresponding stable pointer is no longer required. 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. 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. ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Why I want Haskell finalizers
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...) -- Alastair ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
