Dynamic libraries and GHCi
marlowsd at gmail.com
Mon May 10 05:06:21 EDT 2010
We had planned to switch to using a dynamically-linked GHCi for 6.14.1
(see http://hackage.haskell.org/trac/ghc/ticket/3658), which on the
whole seems like the right direction to be heading in, since we reduce
the dependence on our own RTS linker.
The dynamically-linked GHCi works, and passes all the tests. It also
starts up faster than the statically linked one, at least on Linux,
possibly due to a combination of the system linker being faster than
ours and it doing on-demand linking. That's the good news.
But I've realised this transition won't be as easy as I thought.
Currently if you build a package dynamically (Cabal's --enable-dynamic),
then you get a completely separate build of the package, with its own
interface files and so on - it's a "way", in the same sense as
profiling. This seemed obviously the sensible thing to do, since we
really are compiling the code multiple times, and the results might be
different. However, it gives us a problem with GHCi. If GHCi is
dynamically linked, then it can only load object code that is compiled
with -dynamic, because then the object code will be compiled against the
right .hi files.
I see only three possibilities:
- we make -dynamic the default.
- we somehow make the two ways compatible. This would probably
entail compiling both versions at the same time, so we get
the same Core, but running the code generator twice.
I think there might be some technical problems with doing
this, as we sometimes turn static data into dynamic data
when compiling with -dynamic. If we could work around this,
though, the general idea would still require a lot of changes
in build systems, Cabal, GHC and so on.
- packages should have predictable & stable ABIs. I've been
wanting to do this for a long time, but we're not ready yet,
and even so I hadn't planned to impose stable ABIs on every
package - e.g. doing this for the base package would probably
limit cross-module optimisation too much.
It's perhaps worth investigating the consequences of the first option,
making -dynamic the default. Cabal would have to --enable-dynamic by
default - perhaps it would get an --enable-static that could even be
*off* by default.
We would have to measure the performance implications carefully. I know
that right now the GC takes quite a severe performance hit (about 30% or
so) when compiled with -fPIC on x86, due to losing the %ebx register. I
think that's unacceptable, but I haven't managed to fix it yet.
I don't have a clear idea for how to proceed, so I thought I'd describe
the issues here and see if we can come up with a plan.
More information about the Glasgow-haskell-users