September 2002 - FFI - Haskell.org

RE: Cheap ForeignPtr allocation
by Simon Marlow 12 Sep '02

12 Sep '02

> > [...] using a ForeignPtr here, with free() as its finalizer, adds so > > much overhead that [...] > > Where is the overhead coming from? Is it the cost of a C call or the > cost of the standard malloc library? It's the combined cost of - malloc() - creating a weak pointer to register the finalizer - running the finalizer - free() I can't remember the exact break-down, but I believe more than half the cost is in malloc+free. > If the latter, I imagine that a > custom allocator would have similar performance to using pinned > objects. Yes, using a custom allocator is likely to get you most of the benefit (I say most, because you'd still need a finalizer and a free() routine, compared to GC). But this is an argument in favour of the new interface, because it abstracts away from the actual allocator used, so the implementor is free to provide a custom allocator. That's a win, isn't it? > (I'm sort of assuming that pinned objects are more expensive > than normal objects.) > > btw I don't know if it's relevant but there's an important semantic > difference between allocating on the GHC heap and allocating on the C > heap. The C version can be manipulated by the malloc.h functions. In > particular, you can call realloc on it. Do that on the GHC heap > version and... well, it won't be pretty. I don't know if this is > relevant because using realloc with ForeignPtr'd memory is likely to > be a delicate procedure no matter how it got allocated. Yes, I thought about this. Fortunately a ForeignPtr isn't mutable, even using GHC extensions, so I can't see a way to safely call realloc() once you've made a ForeignPtr. Anyway, the docs for mallocForeignPtr would have to say something like "the pointer is not guarnateed to have been returned by malloc()". Cheers, Simon

2 1

Re: isNull{Fun,}Ptr
by Marcin 'Qrczak' Kowalczyk 12 Sep '02

12 Sep '02

Wed, 11 Sep 2002 16:42:55 +1000 (EST), Manuel M T Chakravarty <chak(a)cse.unsw.edu.au> pisze: > Sure, but there is also > > null = (== []) > > in the Prelude and `Maybe.isNothing'. Because they work even if list element type or the type argument of Maybe isn't Eq. There is no analogous need for null pointers (as for numeric 0). -- __("< Marcin Kowalczyk \__/ qrczak(a)knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

1 0

isNull{Fun,}Ptr
by Manuel M T Chakravarty 11 Sep '02

11 Sep '02

Wolfram Kahl suggested to add functions isNullPtr and isNullFunPtr (with the expected semantics) to the Ptr module. Opinions? Manuel

2 4

RE: Updates to FFI spec
by Simon Marlow 11 Sep '02

11 Sep '02

> > System.Mem.performGC does a major GC. When would a partial GC be > > enough? > > I've described the image-processing example a bunch of times. > > We have an external resource (e.g., memory used to store images) which > is somewhat abundant and cheap but not completely free (e.g., > eventually you start to swap). It is used up at a different rate than > the Haskell heap so Haskell GCs don't occur at the right times to keep > the cost low and we want to trigger GCs ourselves. Hmmm, the garbage collector is a black box and has its own complicated heuristics for managing memory usage, but you are describing a mechanism that depends rather heavily on certain assumed behaviours. At the least, that gives the garbage collector less flexibility to change its own behaviour, lest it invalidate the assumptions made by the external allocator. > (In the image > processing example, images were megabytes and an expression like (x + > (y * mask)) would generate 2 intermediate images (several megabytes) > while doing just 2 reductions in Haskell.) I think I'd be tempted to try to use a more predictable allocation scheme given the size of the objects involved. Perhaps arenas? > How often and how hard should we GC? We can't do a full GC too often, > or we'll spend a lot of time GCing, destroy our cache and cause > premature promotion of Haskell objects into the old generation which > will make the GC behave poorly. So if all we can do is a full GC, > we'll GC rarely and use a lot of the external resource. > > Suppose we could collect just the allocation arena. That would be > much less expensive (time taken, effect on caches, confusion of object > ages) but not always effective. It would start out cheap and > effective but more and more objects would slip into older generations > and have to wait for a full GC. > > To achieve any desired tradeoff between GC cost and excess resource > usage, we want a number of levels of GC: gc1, gc2, gc3, gc4, ... Each > one more effective than the last and each one more expensive than the > last. We'll use gc1 most often, gc2 less often, gc3 occasionally, gc4 > rarely, ... But there seems to be no way to reasonably decide how often one should call these. Doesn't it depend on the garbage collector's own parameters too? > > I think the spec should be clarified along these lines: > > > Header files have no impact on the semantics of a foreign call, > > and whether an implementation uses the header file or not is > > implementation-defined. Some implementations may require a header > > file which supplies a correct prototype for the function in order to > > generate correct code. > > I still don't like the fact that compilers are free to ignore header > files. Labelling it an error instead of a change in semantics doesn't > affect the fact that portability is compromised. I don't see any alternative - would you require a compiler that has only a native code generator to read header files? When there's no C compiler on the system? (this is realistic - at some point we'd like to make the via-C route in GHC completely optional, so we can ship a compiler on Windows that doesn't need to be bundled with GCC). > > Perhaps on GHC you should be required to "register" the top module > > in your program first, maybe something like > > > registerModule(__stginit_Main); > > > that way you can register multiple modules (which isn't possible at > > the moment, you have to have another module which imports all the > > others). > > What does that do? Is it for threading, GC, profiling, ...? Each module has a little initialisation fragment that calls all the initialisation fragments for the modules it imports. At the moment, there are two kinds of initialisation done for each module: - each foreign export is registered as a stable pointer. This prevents the garbage collector from collecting any CAFs which might be required (indirectly) by a foreign export. - when profiling, all the cost centres in the current module are initialised. It might be possible to do this using linker sets, but I haven't tried (and it would probably be highly non-portable too). Cheers, Simon

3 6

Re: Proposed change to ForeignPtr
by George Russell 11 Sep '02

11 Sep '02

Manuel wrote (snipped) > I have changed this in the spec now. I attach the wording > used in the spec. > \item[newForeignPtr ::\ Ptr a -> FunPtr (Ptr a -> IO ()) -> IO (ForeignPtr a)] > Turn a plain memory reference into a foreign object by associating a > finalizer with the reference. The finalizer is represented by a pointer to > an external function, which will be executed after the last reference to the > foreign object is dropped. On invocation, the finalizer receives a pointer > to the associated foreign object as an argument. Note that there is no > guarantee on how soon the finalizer is executed after the last reference was > dropped; this depends on the details of the Haskell storage manager. The > only guarantee is that the finalizer runs before the program terminates. > > Whether a finaliser may call back into the Haskell system is system > dependent. Portable code may not rely on such call backs. > > \item[addForeignPtrFinalizer ::\ ForeignPtr a -> FunPtr (Ptr a -> IO ()) -> IO > ()] Add another finalizer to the given foreign object. No guarantees are > made on the order in which multiple finalizers for a single object are run. I think this is all a rather murky area. Consider two systems, let's call them Haskell and Foogle, which both operate heaps and do their own storage allocation, but also communicate over similar FFIs. We might very reasonably have situations where fairly complex inter-language pointers exist, so for example Haskell holds a ForeignPtr to something in the Foogle heap; the pointed-to Foogle object in turn references a Haskell object (presumably provided via StablePtr). Now suppose Haskell wants to drop the ForeignPtr. Then the logical thing for the finalizer to do is to tell Foogle that Haskell is no longer interested in the Foogle object. This then gives Foogle the chance on its own garbage collection to in turn drop the Haskell StablePtr. In turn this means somehow running StablePtr.freeStablePtr. However this scheme I don't know if that's legal, because the Haskell finalizer you need to run "freeStablePtr" is indirectly provoked by the initial Haskell finalizer. This is a pity, because this might actually be a fairly good way of managing garbage collection between Foogle and Haskell. Of course you would need at least reference counters (if you can guarantee there are no cycles containing both languages) or something more powerful otherwise, but reference counters at least can be provided. Furthermore I do actually have a real case in mind where I might use something like this, though I'd rather not go into details at this time. I'm afraid I haven't been following this thread lately, so I don't know what the big problem is about calling Haskell from a finalizer; I suppose it's something to do with us being in the middle of garbage collection. However wouldn't it be better to allow finalizers to somehow provide an action which may call Haskell, but (a) may be performed at some later date (such as when the GC is over); (b) consequently, may not assume that the pointer finalized still points to anything?

4 5

RE: Proposed change to ForeignPtr
by Simon Marlow 11 Sep '02

11 Sep '02

I'm afraid George's questions have also rekindled my curiosity about whether implementing Haskell finalizers is really as hard as it sounds. Much has been written, but I still don't think we've got to the nub of the issue. On the face of it, if you can implement 'foreign import ccall safe', then you have a re-entrant runtime system. The times at which the program can make one of these foreign calls are limited, i.e. in the IO monad only - but I believe there's nothing particularly special about IO computations in the evaluation models used by nhc98 and Hugs (correct me if I'm wrong). Alastair writes: > The way GHC implements preemption is an optimized form of: set a bit > when preemption is needed; and make sure that generated code will test > that bit whenever it is in a position to perform a context switch. > > What you're asking Hugs and NHC to do is: add a function to a list > whenever you have a finalizer to run; make sure the interpreter will > test that bit whenever it is in a position to perform a context > switch. > > It's basically the same. We don't have to mess around with signals to > provide a regular timer interrupt but that's the easy bit of the code. Ok so far. > We can probably avoid messing around with multiple C stacks. That's a > significant saving but, it's the complexity of that is fairly > self-contained - we could probably steal some code from some other > language implementation. > > The cost is going over all data structures in the system making sure > that operations on them are suitably atomic. One of the issues I > remember from old versions of GHC was that some of the primops would > do some work, allocate some memory, then finish the job. The classic > error to make in that code was for the second half of the code to > assume almost anything about what happened in the first half of the > code: how much space is on the stack, does a table have free space in > it, is this pointer into the middle of an object ok? You certainly can't keep local variables live across a heap check, everything has to be saved on the stack. Hugs is different because it has a conservative GC, so doesn't need to save everything on the stack for a GC. But how does it implement a safe foreign call? Presumably it must save away state on the stack in a way that the computation can be resumed safely, and that's all you need in order to be able to run a Haskell finalizer. > The problem is the scope: every single data structure and every bit of > code that accesses it has to be vetted and we have to keep it in mind > as we maintain the code. It's a high price to pay and I don't think > it's necessary (because all you really need is for the runtime systems > to talk to each other in very limited ways). I don't quite understand this: could you give a concrete example of some extra invariant that has to be maintained? In GHC, context switches happen at very precise points (i.e. heap checks) so I don't think we have these kind of problems; certainly I don't remember vetting every single data structure. Can't Hugs use a similar approach? Cheers, Simon

1 0

RE: Proposed change to ForeignPtr
by Simon Peyton-Jones 11 Sep '02

11 Sep '02

I confess that I have not followed the twists and turns of this discussion, but it seems to have gotten more complicated than necessary. There are several separate issues. 1. Can a finaliser for a Haskell value be an arbitrary Haskell computation? For GHC, yes. For Hugs, no (and for good reasons). So Hugs can only allow a C procedure as a finaliser. 2. If a garbage collector (whether the Haskell gc or the Foogle gc) finds that it is dropping a pointer to an object, when may it run the finalizer? Answer: it should be allowed to do so at any time: when the pointer is dropped (for ref-count gc) or during gc (as Hugs does) or after gc (as GHC does). 3. If the finalizer, in turn, needs to call some kind of foreign 'free' routine (e.g. the finaliser for a Haskell object encapsulating a Foogle object calls the Foogle free code; or the finalizer for a Foogle object encapsulating a Haskell value calls the Haskell free routine) it should be allowed to do so at any time. BUT DOING SO DOES NOT trigger an immediate GC in the other system. Several people have explained why it would be bad to trigger immediate GC. All the 'free' routine does is record that Foogle no longer holds this pointer (or vice versa). That information (as Alastair puts it) tweaks local data structures (yes, there may need to be a lock if there are separate OS threads involved), and that info is exploited at the next GC. 4. None of this says anything at all about asynchronous calls into (say) Haskell from Foogle. I don't understand what the issues are exactly. Simon

2 1

Re: Proposed change to ForeignPtr
by George Russell 11 Sep '02

11 Sep '02

Malcolm Wallace wrote [snip] > When sequential control returns to the Foogle world, that is when > the Haskell GC is guaranteed to be complete. [snip] I don't think I recognise this notion of "sequential control". It seems to be assuming there is only one "real" OS thread in existence, and it is impossible for both Foogle and Haskell to have "sequential control" over this thread at any given moment. When they do not have sequential control, they are not allowed to perform garbage collection. This model no doubt fits NHC well enough, but it seems to be assuming an awful lot about Foogle or about the system you are running on. To take a concrete example, suppose Haskell == NHC and Foogle = GHC, then it seems to me the model breaks down because I imagine GHC is quite happy to do GCs and invoke finalizers in the middle of exported functions. Even worse, GHC at least is now capable thanks to Sigbjorn of running in several OS threads at once (on Windows) so it may be doing GCs at any time whatever. I appreciate it's not Malcolm Wallace's fault that NHC can't implement a form of dynamic wrapper which can be used at all times. However since I do not think this problem is going to go away, would it not be better to put it in the specification but admit that NHC can't do it? Otherwise the FFI specification will be very good (as it is) if you want to call languages like C, but will be inadequate if you want to communicate with other languages which also know about things like concurrency and garbage-collection, such as Haskell or even Java.

2 4

module Data.Bits
by Malcolm Wallace 11 Sep '02

11 Sep '02

I have just been implementing the library module `Data.Bits' for nhc98, as part of an effort to bring that compiler up-to-date with the latest FFI spec. The FFI spec says that the operations called 'shift' and 'rotate', shift and rotate their argument to the right. However, the GHC implementation in CVS shifts and rotates to the left, and is documented to do so. Who is right? FWIW, before I read any documentation I expected the undecorated forms to be rightward. Regards, Malcolm

3 8

RE: module Data.Bits
by Simon Marlow 11 Sep '02

11 Sep '02

> The FFI Addendum actually doesn't commit to which operations > are in the class. It just says defines all these ops to > have a context `Bits a', which is definitely the case. In > other words, you proposed implementation is valid by the > spec and your argument for it makes sense to me. The spec really ought to say what the member functions of the class are, if we expect people to be able to define their own instances of Bits, and I don't see why we shouldn't allow that. I think Malcolm's proposed change looks reasonable, although there was probably a reason why these functions weren't made class members in the first place. Alastair: it was your design originally I believe, any thoughts? I think it would be a small optimisation in GHC too, at least for shifts by non-constant amounts. Cheers, Simon

3 2