Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | GC refactoring and cleanup | Simon Marlow | 2011-02-02 | 1 | -5/+2 |
| | | | | | | | | | Now we keep any partially-full blocks in the gc_thread[] structs after each GC, rather than moving them to the generation. This should give us slightly better locality (though I wasn't able to measure any difference). Also in this patch: better sanity checking with THREADED. | ||||
* | Fix the symbol visibility pragmas | Simon Marlow | 2010-06-17 | 1 | -2/+2 |
| | |||||
* | Move a thread to the front of the run queue when another thread blocks on it | Simon Marlow | 2010-03-29 | 1 | -0/+2 |
| | | | | | | | This fixes #3838, and was made possible by the new BLACKHOLE infrastructure. To allow reording of the run queue I had to make it doubly-linked, which entails some extra trickiness with regard to GC write barriers and suchlike. | ||||
* | GC refactoring, remove "steps" | Simon Marlow | 2009-12-03 | 1 | -1/+1 |
| | | | | | | | | | | | | | | | | | | | | | The GC had a two-level structure, G generations each of T steps. Steps are for aging within a generation, mostly to avoid premature promotion. Measurements show that more than 2 steps is almost never worthwhile, and 1 step is usually worse than 2. In theory fractional steps are possible, so the ideal number of steps is somewhere between 1 and 3. GHC's default has always been 2. We can implement 2 steps quite straightforwardly by having each block point to the generation to which objects in that block should be promoted, so blocks in the nursery point to generation 0, and blocks in gen 0 point to gen 1, and so on. This commit removes the explicit step structures, merging generations with steps, thus simplifying a lot of code. Performance is unaffected. The tunable number of steps is now gone, although it may be replaced in the future by a way to tune the aging in generation 0. | ||||
* | Refactoring only | Simon Marlow | 2009-12-02 | 1 | -0/+47 |