|
|
## Status
|
|
|
|
|
|
|
|
|
I'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.
|
|
|
|
|
|
- I think Option 3 is the most robust, but I don't know how to pull it off.
|
|
|
|
|
|
- Option 6 sounds best after that, but it was a late idea and I'm not sure how robust the underlying mechanism is.
|
|
|
|
|
|
- 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.
|
|
|
|
|
|
## Background
|
|
|
|
|
|
### `CoreMonad.reinitializeGlobals`
|
... | ... | @@ -70,6 +81,9 @@ string_table :: IORef FastStringTable |
|
|
|
|
|
During 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.
|
|
|
|
|
|
|
|
|
It'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.
|
|
|
|
|
|
### Option 1: The General Solution
|
|
|
|
|
|
|
... | ... | @@ -187,3 +201,8 @@ Performance: I'm hoping pointer tagging, unpacking (will this sum type be unpack |
|
|
|
|
|
|
|
|
This 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.
|
|
|
|
|
|
### Option 6: Use `UniqSupply` in `FastString`
|
|
|
|
|
|
|
|
|
Instead 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. |