Dynamically link GHCi (and use system linker) on platforms that support it
|Reported by:||simonmar||Owned by:||thoughtpolice|
|Keywords:||dynamic link||Cc:||morrow@…, howard_b_golden@…, pho@…, dterei, bos@…, george.colpitts@…, hvr, andreas.voellmy@…|
|Type of failure:||None/Unknown||Test Case:|
|Blocked By:||Blocking:||#1883, #3242, #3372, #3654, #4244, #5062, #7072, #7316, #7389, #7475, #7687|
|Related Tickets:||Differential Rev(s):|
Description (last modified by ezyang)
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).
- 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
- 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), 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.
- 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.
Change History (59)
comment:13 Changed 4 years ago by igloo
- Blocked By 5987 added
- Blocking 1883, 2283, 3242, 7097, 7134 added
comment:17 Changed 4 years ago by igloo
- Blocking 3372, 3654, 4244, 5062, 5197, 6107 added
- Owner set to igloo
- Summary changed from Dynamically link GHCi on platforms that support it to Dynamically link GHCi (and use system linker) on platforms that support it
comment:39 Changed 3 years ago by george.colpitts
- Cc george.colpitts@… added
- Keywords dynamic link added
comment:55 Changed 2 years ago by thoughtpolice
- Blocked By 5987 removed
- Resolution set to fixed
- Status changed from new to closed