Changes between Version 7 and Version 8 of Plugins/ReinitializeGlobals


Ignore:
Timestamp:
Jul 5, 2013 4:51:28 PM (10 months ago)
Author:
nfrisby
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Plugins/ReinitializeGlobals

    v7 v8  
    11[[PageOutline]] 
     2 
     3== Status == 
     4 
     5I've pushed Option 2 to HEAD. Since then, I've realized the troubles with laziness are more delicate than I thought, so I came up with Options 5 and 6. 
     6 
     7  * I think Option 3 is the most robust, but I don't know how to pull it off. 
     8 
     9  * Option 6 sounds best after that, but it was a late idea and I'm not sure how robust the underlying mechanism is. 
     10 
     11  * Option 5 avoids the laziness issues, but we'll have to ensure it doesn't adversely affect performance too much — `FastString` has some hot spots. 
    212 
    313== Background == 
     
    6373 
    6474During its use, the `FastString` table increments the `!Int` argument. `reinitializeGlobals` alone is incapable of supporting this appropriately; it was designed to only copy global variables' values from the host compiler to the plugin, never in the opposite direction. Those original global variables were global for convenience of access, not for the need to be mutable. The `FastString` table breaks the mold. 
     75 
     76It's straight-forward to have the two images share the array, but it is difficult to keep the two images' values of `Int` in synch.  The danger is that the two images could allocate the same unique for distinct `FastString`s — that'd break a major invariant. 
    6577 
    6678=== Option 1: The General Solution === 
     
    155167 
    156168This Option does not have any laziness issues. Thunks that end up adding `FastString`s to the table, when forced, always begin by reading the `string_table` `IORef`.  Thus, they will see the `Just_FST` if they're forced after `reinitializeGlobals`, regardless of when those thunks were created.  In other words, thunks only cache the `IORef`, not its contents. Since each image's `IORef`'s contents now includes a reference to the other image's `IORef`, the thunks will mutate both tables in synch. 
     169 
     170=== Option 6: Have the `FastString` module use `UniqSupply` === 
     171 
     172Instead of allocating `FastString`s' uniques linearly, let's use a `UniqSupply`. Then we'd just need to split the supply in order to prevent the danger of two `FastString`s getting the same unique. Whatever routine does the splitting just needs to be called the first time libHSghc is loaded dynamically and never again.