Changes between Version 13 and Version 14 of Plugins/ReinitializeGlobals


Ignore:
Timestamp:
Jul 6, 2013 10:56:41 PM (2 years ago)
Author:
nfrisby
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Plugins/ReinitializeGlobals

    v13 v14  
    77  * SPJ likes the overall interface changes in Option 1 (ie `workAroundGlobals`) for future-proofness, beyond just this issue with the globals.
    88
    9   * I think Option 3 is the most robust, but I don't know how to pull it off. Simon Marlow weighed-in with a great pointer, which I'm digesting now:
     9  * Ian Lynagh asks "why not just us a dynamically linked compiler?". That seems to be a possible prerequisite for using plugins, but I don't know the wider repercussions (eg all the platforms etc).
    1010
    11   "I haven't been following this in detail, but I think you're encountering the same problem we had with various top-level IORefs in the base package.  The solution we have there is grotesque but it works.  Take a look at libraries/base/GHC/Conc/Signal.hs, search for getOrSetGHCConcSignalSignalHandlerStore.  There is some corresponding RTS gunk to help with this in rts/Globals.c."
     11  * I think Option 3 is the most robust.
    1212
    1313  * Option 6 sounds best after that, but it was a late idea and I'm not sure how robust the underlying mechanism is.
     
    136136So the rule would be: ''Do not let the compiler force any of a plugin's thunks that allocate `FastString`s, and vice versa.'' (Same for Option 1.)
    137137
    138 === Option 3: The Full Low-Level Hack ===
     138=== Option 3: The Full Low-Level Swap ===
    139139
    140 Can we do some dirty low-level pointer copying so that the plugin's `FastString.string_table` CAF is a `IND_STATIC` pointing to the compiler's `FastString.string_table` CAF?
     140Simon Marlow said:
    141141
    142 This would be the least invasive approach wrt the GHC source code by far and it would have no rules for the plugin author to worry about.
     142  "I haven't been following this in detail, but I think you're encountering the same problem we had with various top-level IORefs in the base package.  The solution we have there is grotesque but it works.  Take a look at libraries/base/GHC/Conc/Signal.hs, search for getOrSetGHCConcSignalSignalHandlerStore.  There is some corresponding RTS gunk to help with this in rts/Globals.c."
     143
     144This workaround keeps a table of `StgStablePtr`s in the RTS for a fixed set of symbols (that's managed by `rts/Globals.c`). That table is accessed via C functions named with the scheme `getOrSet<key>`. So we add one such function there (and in `includes/rts/Globals.h`: `getOrSetLibHSghcFastStringTable`.
     145
     146The mechanism is invoked thusly:
     147
     148{{{
     149{-# NOINLINE string_table #-}
     150string_table :: IORef FastStringTable
     151string_table =
     152 unsafePerformIO $ do
     153   tab <- IO $ \s1# -> case newArray# hASH_TBL_SIZE_UNBOXED [] s1# of
     154                           (# s2#, arr# #) ->
     155                               (# s2#, FastStringTable 0 arr# #)
     156   ref <- newIORef tab
     157   sharedCAF ref getOrSetLibHSghcFastStringTable
     158
     159foreign import ccall unsafe "getOrSetLibHSghcFastStringTable"
     160  getOrSetLibHSghcFastStringTable :: Ptr a -> IO (Ptr a)
     161}}}
     162
     163Thus there ever exists only one such CAF per process, regardless of how many copies of libHSghc are loaded, since they all share the first such CAF forced. This is arbitrated by the process's sole image of the RTS.
    143164
    144165=== Option 4: Do Nothing ===