Dynamically link GHCi (and use system linker) on platforms that support it
In 6.14.1 we should switch to shipping a dynamically linked GHCi binary, on those platforms for which dynamic linking is supported (currently Linux; MacOS X and Windows support is in progress).
Advantages
-
The GHCi binary is smaller
-
some packages don't need to be loaded on startup: lower memory use
-
GHCi startup might be quicker (or it might not)
-
some hacks due to having two copies of the base package are not
necessary (see
rts/Globals.c
) -
We might save some space in the distributions.
-
It takes us a step closer to not needing the RTS linker at all
-
It takes us a step closer to using dynamic linking by default, which
is where we want to go ultimately
Potential Issues
-
Do we run into any problems with GHCi and the user program sharing the same
stdin/stdout/stderr handles? Do we need to virtualise these explicitly in the
GHCi front end?
-
We cannot revert CAFs in packages that are shared by GHC and the user program.
There are some old non-working hacks related to reverting CAFs when GHCi is
dynamically linked (see
KeepCAFsForGHCi
) thatneed to be cleaned out. CAFs can only be reverted in code loaded by the RTS
linker. We need to think about whether this is a necessary feature or not:
we have never supported CAF reverting for interpreted code anyway. One
reason to have it was so that you can recover after saying
getContents
atthe GHCi prompt, but we can provide other ways to work around that. However, if
we eliminated HEAP_ALLOCED (#8199 (closed)), as a side effect of this implementation,
this might be doable, as we no longer have to reach our fingers into the
data section of dynamically linked in libraries to revert a CAF; all of the CAFs
are copied to dynamic memory space first. (The current implementation doesn't
work for that, however!)
-
There will be installation/binary-dist issues to resolve; currently we don't
install any dynamically-linked binaries.
Open questions
-
Whether we continue to use the same binary for GHC and GHCi is an open question:
it would be possible to provide a separate statically-linked GHC binary if
performance of the dynamically-linked version was an issue.
-
We might as well dynamically-link Haddock, and the other tools that come
with GHC too.