Skip to content

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) that

    need 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 at

    the 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.

Edited by Edward Z. Yang
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information