
Magnus Therning wrote:
On Fri, Oct 3, 2008 at 12:59 PM, Simon Marlow
wrote: Dynamic linking doesn't solve all the problems, we still have the problem that GHC does a lot of cross-module inlining, regardless of whether dynamic linking is used. However, I really would like to have a way to have complete control over what is exposed across a package boundary. We need this not just for licensing reasons, but also for making a dynamic library with a fixed ABI, so it can be upgraded later. I have a really hard time following this. Are you seriously saying
On Wed, Oct 1, 2008 at 6:03 PM, Simon Marlow
wrote: [..] that GHC is inlining code from modules _and_ link dynamically at the same time. That seems like a remarkably strange thing to do, or maybe I'm just missing something. That's exactly what would happen, if we shipped dynamic linking support with GHC as it stands. It's just a linking mechanism, an alternative to static Magnus Therning wrote: linking, and has no impact on the amount or nature of inter-module optimisation that GHC does.
Ah, now I understand. The object for GHC would be to reduce the system-wide use of memory rather than substitutability of DLLs then, right?
Why would it be interesting to have sharable objects without substitutability?
It'll make our binary distributions a lot smaller for one thing. Also, the on-disk size of binaries will be a lot smaller - this is something you notice if you run a GHC test suite, for example. Also, the GHCi binary contains the base package, but loads up another complete copy when it starts up. And if you load up the GHC package inside GHCi, then you have two complete copies of GHC in memory. Dynamic linking fixes all this. Cheers, Simon