Changes between Version 4 and Version 5 of GarbageCollectorNotes

May 15, 2006 5:58:10 PM (11 years ago)



  • GarbageCollectorNotes

    v4 v5  
    144144== Copy ==
     146= Motivation for Parallelization =
     148The essential idea is best described here:
     149[refer to the flood paper]
     151It is helpful to be aware of copy collection and mark-compact collection before you read the above paper. The Richard Jones and Raphael Lins text on Garbage Collection is a recommended resource.
     153For our garbage collector, we are yet to work out the details of how Gen0 should be compacted. The best idea for later generations is some variant of the work stealing approach proposed in the above paper. This of course might change in the course of the project.
    146155== Measurement of Block Distance while Scavenging ==
     157Here are some plots of block distance against the collection number and the average block distance and the collection number. Block distance is defined to be the number of links one has to follow from the scan_bd to reach the hp_bd in a step during garbage collection. If the block distance in 2 then it means that there is atleast one independent block in between the pointers that can be taken up by another thread.
     159The essential idea behind work stealing is that free threads can steal work from busy threads. The work is essentially the work of scavenging live objects. hp_bd points to the top of the to-space where the next free object can go. scan_bd points to the block where the next object to be scanned is. All objects between scan_bd and hp_bd  are objects that are yet to be scanned. A free thread essentially steal a block of objects in this range and can scan them, essentially reducing the load of the busy thread.
     161The following program was used to generate some the graphs below. Changing the treeDepth and the nTrees values below one can get the program to have different memory profiles.
     164import System
     166treeDepth = 17
     167nTrees = 40
     169makeList 0 d = []
     170makeList n d = d : (makeList (n-1) d)
     172main :: IO ()
     173main = if (recVal (makeList nTrees treeDepth)) < 10
     174       then print "###"
     175       else print "##"
     178data Tree a = L a
     179            | B (Tree a) (Tree a)
     181makeTree 0 = L 1
     182makeTree n = B (makeTree (n-1)) (makeTree (n-1))
     184sumTree (L x) = x
     185sumTree (B t1 t2) = 1 + (sumTree t1) + (sumTree t2)
     187treeVal n rest = let tr1 = makeTree n in
     188                     sumTree(tr1) + sumTree(makeTree n) + (recVal rest) + sumTree(tr1)
     190recVal [] = 0
     191recVal (x:xs) = treeVal x xs
     194Here are some plots:
     209Here is how to interpret the graphs. The label ‘#’ on an axis indicates that it is time where each tick is a garbage collection. The label ‘live_objs’ indicates the total number of live objects encountered during this collection. This is not the total number of live objects in the system but only those in the generations currently collected. The value ‘block_dist’ indicates the maximum block distance encountered during a collection.
     211The value `avg_block_dist’ indicates the average block distance encountered during a collection. If you think about the block distance a bit you realize that it essentially starts from zero increases and decreases during the duration of scavenging and finally becomes zero when the scan point catches up with the heap pointer. We wanted to measure approximately the area under this region as a indication of the average chance of parallelization. Further to make the measurement a little less fine grained, it was taken only when a new block was allocated to the to-space. This value can be considered indicative of how much parallelization is possible on average during that GC run. [At least I hope so]
     213Here are similar plots of some programs in the nofib test suite that is available in the GHC source tree.
     215Plots of real/fulsom (with input 8)
     229Plots of real/pic (with input 20000)
     243Plots of real/fem (with fem.stdin)
     251fem did not do an G1 collections.
    179284This behavior would often end with power cycling the laptop and was rather frustrating for a while. After studying the process with procexp, filemon and some standard monitoring tools it seemed like the “Logitech LVPrcSrv module” related to my Logitech webcam seems to hog the CPU. Since I wasn’t using the webcam, I killed the process and the build went through fine. At this point I can’t guess at what the relationship is or why there should be one.
    183287Roshan James (rpjames [at] cs [dot] indiana [dot] edu)