Changes between Version 13 and Version 14 of Plugins/ReinitializeGlobals


Ignore:
Timestamp:
Jul 6, 2013 10:56:41 PM (10 months 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 ===