Opened 13 years ago

Closed 8 years ago

Last modified 3 years ago

#311 closed bug (fixed)

gmp's memory management

Reported by: as49 Owned by:
Priority: low Milestone: 6.12 branch
Component: Compiler (FFI) Version: 6.4
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #9281 Differential Rev(s):
Wiki Page:

Description (last modified by simonpj)

I assume ghc allocates the lumps of gmp integers still on ghc's heap, making it impossible (or very awkward) to interface to C libraries that use gmp themselves. Is there a chance that you could use the default memory allocator for lumps starting from ghc 6.4? That would make my life much easier.

Thanks, Axel.

Change History (14)

comment:1 Changed 13 years ago by simonmar

Logged In: YES 

It's a known problem that you can't use GMP via the FFI from
your Haskell code in GHC, or use a C library that internally
uses GMP.  We should really use a private version of GMP
with function names that don't overlap, or better still
replace GMP altogether.

I don't think this is going to get fixed for 6.4, I'm afraid.

comment:2 Changed 12 years ago by sigbjorn

Logged In: YES 

It wouldn't be too hard to provide an entry point that let you 
enable/disable the use of GHC's custom allocator functions.

That entry point would be called by FFI wrapper code, either 
as a service by the RTS or manually by user code. Would 
only work in single (OS) threaded code, of course.

comment:3 Changed 11 years ago by igloo

Architecture: Unknown
Description: modified (diff)
difficulty: Unknown
Milestone: 6.8
Operating System: Unknown

See also 601.

comment:4 Changed 10 years ago by simonpj

Description: modified (diff)

Comment from Benedict Huber

I've been struggling using FFI bindings to libraries which rely on the GNU Mp Bignum library (gmp) - this is apparently a well known problem (#311, [wiki:ReplacingGMPNotes). I do rely on using such libraries, and so started to get it work on MacOsX; no solution was close to being satisfactory however, so I'd like to ask for some advice.

Those two options worked to some extend:

  • Create or modify the library in question, so gmp is statically linked and its symbols are hidden. When source code is available, this is relatively easy, altough it requires modification of the build process (which can be a hassle). If a static "ar" archive is available, it is cumbersome (at least on Mac Os X I ran into a lot of troubles using nmedit), but possible. Furthermore, the resulting libraries are bloated, as each of them contains a copy of the GMP; left alone portability issues.
  • As suggested an earlier comment, I tried switching the allocator functions when switching to FFI. It worked, but not in GHCi; also, doing it manually is a lot of work, because, as far as I could figure out, it is neccessary to write a wrapper function for every C-function (indirectly) using the gmp.

Furthermore, most of the libraries expose gmp datatypes (mpz_t,mpq_t) in their API. I currently use a little haskell module working on GHC.Exts, but that's propably not a good option from a maintainer's point of view. There are certainly other possibilities, but I couldn't find one which is both maintainable and portable.

I would be very grateful for any advice, or some information on plans for resolving ticket #311. There are some great libraries (like the Parma Polyhedral Library, to pick an example) out there using gmp, and it would be nice if writing bindings to those libs could be simplified.

Thanks, Benedikt Huber

comment:5 Changed 10 years ago by simonmar

Milestone: 6.8 branch6.10 branch
Owner: nobody deleted
Status: assignednew

comment:6 Changed 9 years ago by guest

comment:7 Changed 9 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:8 Changed 9 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:9 Changed 9 years ago by judahj

In the following post, Aleš Bizjak suggests the following workaround: use the foreign library's custom memory interface, and allocate with malloc.

comment:10 Changed 9 years ago by igloo

Milestone: 6.10 branch6.12 branch

comment:11 Changed 8 years ago by igloo

Resolution: Nonefixed
Status: newclosed

It is now possible to build GHC with a pure Haskell Integer library, so I'm closing this ticket.

comment:12 Changed 8 years ago by isaacdupree

It's still a bug/issue for when GHC is built with GMP. Were we planning on switching to non-GMP as default or mandatory? (I think such a change would need more discussion, because some code might use the speed of GMP's algorithms on large numbers.) I guess just having non-gmp as a configure choice is a workaround for these users, although not a perfect or easy workaround

comment:13 Changed 8 years ago by igloo

It's also now easy to create alternative integer backends, e.g. using a renamed gmp, or another C integer library. I don't think we intend to do anything else on this front, though.

GMP will remain the default.

comment:14 Changed 3 years ago by hvr

Type of failure: None/Unknown

See #9281 for a new attempt to improve the situation for the integer-gmp

Note: See TracTickets for help on using tickets.