[GHC] #8039: RTS linker: unloadObj() does not actually unload the code
GHC
ghc-devs at haskell.org
Sun Jul 7 22:53:13 CEST 2013
#8039: RTS linker: unloadObj() does not actually unload the code
-------------------------------------+------------------------------------
Reporter: simonmar | Owner: simonmar
Type: task | Status: new
Priority: high | Milestone: 7.8.1
Component: Runtime System | Version: 7.6.3
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case: | Blocked By:
Blocking: | Related Tickets:
-------------------------------------+------------------------------------
Comment (by simonmar):
Replying to [comment:8 igloo]:
> My plan was to leave it in 7.8, but not used by default, and then to
remove it from HEAD shortly after 7.8.1 is released. The goal is to stop
maintaining the ghci linker, after all!
I thought we had some platforms that didn't have dynamic linking support,
e.g. ARM/Linux?
I personally don't care if we get rid of the MACH-O support, and maybe
even the COFF support from the linker. The ELF support is fairly solid
though, and for the use case I'm interested in we don't run into any of
the known limitations.
Maybe I could use shared libraries. But (a) this is a scenario where
dynamic linking is generally shunned because it creates more problems than
it solves (deploying to large numbers of machines), (b) we really care
about performance, and dynamic linking adds unnecessary overhead, and (c)
we need to unload objects, and I don't know how to do that with shared
libraries yet.
I still buy the arguments for moving to dynamic linking for GHCi. But
applications with plugin support is a use case we weren't really thinking
about during that discussion, and I think the tradeoffs are different.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8039#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list