Opened 9 years ago

Closed 5 years ago

Last modified 5 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: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

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 (13)

comment:1 Changed 9 years ago by simonmar

Logged In: YES 
user_id=48280

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 9 years ago by sigbjorn

Logged In: YES 
user_id=232905

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 8 years ago by igloo

  • Architecture set to Unknown
  • Description modified (diff)
  • Difficulty set to Unknown
  • Milestone set to 6.8
  • Operating System set to Unknown

See also 601.

comment:4 Changed 7 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 6 years ago by simonmar

  • Milestone changed from 6.8 branch to 6.10 branch
  • Owner nobody deleted
  • Status changed from assigned to new

comment:6 Changed 6 years ago by guest

comment:7 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:8 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:9 Changed 6 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.

http://www.haskell.org/pipermail/haskell-cafe/2008-October/048812.html

comment:10 Changed 5 years ago by igloo

  • Milestone changed from 6.10 branch to 6.12 branch

comment:11 Changed 5 years ago by igloo

  • Resolution changed from None to fixed
  • Status changed from new to closed

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

comment:12 Changed 5 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 5 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.

Note: See TracTickets for help on using tickets.