[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