P.M. Sansom and S.L. Peyton Jones. Generational garbage collection for Haskell In Proceedings of the ACM conference on Functional Programming Languages and Computer Architecture, Copenhagen, June 1993  Home/Search   Document Details and Download   Summary   Related Articles   Check

....than the older generations, despite the fact that young objects have not had much time to die. The weak generational hypothesis is important. Its generalization, the strong generational hypothesis, postulates a negative correlation between age and mortality rate even for long lived objects [19, 29, 30, 36]. There is little empirical support for the strong generational hypothesis. Although some of our own data on object lifetimes provide new support for the strong hypothesis, our data also show why the strong hypothesis does not matter very much: There cannot be a strong negative correlation between ....

Patrick M. Sansom and Simon L. Peyton Jones. Generational garbage collection for Haskell. In Conference on Functional Programming Languages and Computer Architecture, 1993, pages 106--116.

....the benchmark division by 2 in the Gabriel suite [9] These benchmarks are used to test whether avoidance of major collections can balance extra allocation overhead. Here, we explain some terminology. The residency of a program at a particular moment is the size of its live heap allocated data [14]. The average residency was 12 obtained by forcing our leveled garbage collector to determine the amount of live data after each 0.5 MB allocation. We refer to the maximum residency of a program as its problem size. Each benchmark is in fact scalable in problem size. In our evaluation, a wide ....

Patrick M. Sansom and Simon L. Peyton Jones. Generational garbage collection for haskell. In Proceedings of the

....the old heap, i.e. tenured, by the garbage collector, to make separate garbage collection of new and young nodes possible. 1 The criteria for tenuring a node varies between dioeerent generational garbage collectors. The simplest is to tenure all nodes that survive one garbage collection [App89] [SJ93] [Sew92] this is called a simple generational collector in this paper. A more traditional method is to tenure nodes that survived some number of minor collections. It is also possible to have dioeerent tenuring ages for dioeerent node types, or even to prevent tenuring completely for some node ....

....It is only updates that can create pointers from old nodes to young nodes. The old to young pointers can be kept in a table, called the exception table, so that the garbage collector can nd these pointers without scanning the old heap. Other methods are to use indirect tables [LH83] linked lists [SJ93] or card marking [WM89] The latter uses a bit eld to mark if a group of nodes (card) contain any pointers into the new heap. It is easy for the garbage collector to update the exception table when adding nodes to the old generation. The problem is that the mutator updates nodes in the old heap. ....

[Article contains additional citation context not shown here]

Patrick M. Sansom and Simon L. Peyton Jones. Generational garbage collection for haskell. In Proc. 6th Int'l Conf. on Functional Programming Languages and Computer Architecture (FPCA'93), pages 106116. ACM Press, June 1993.

....We chose the current garbage collection scheme because of its simplicity and since we already had a working implementation. From a performance point of view, however, it seems very likely that a generational collector would be preferable (see section 10.4) Seward [Sew92] Sansom Peyton Jones [SPJ93], and R#jemo [R#j95] have all considered generational garbage collection in a lazy context. See Wilson [Wil92] for a survey of dioeerent garbage collection techniques. Paper width: 469.47046pt Paper height: 682.86613pt April 28, 1998 22:03 Job: thesis Sheet: 177 Page: 164 164 CHAPTER 9. SYSTEM ....

Patrick M. Sansom and Simon L. Peyton Jones. Generational garbage collection for Haskell. In Conference on Functional Programming Languages and Computer Architecture (FPCA '93), pages 106116, Copenhagen, Denmark, June 1993. ACM Press.

....are moved into the old heap. This works very well since every speci c part of the structure is only needed for a short time, and is therefore never moved into the old heap. However note that some lazy programs work well even when all nodes that survives one collection are moved into the old heap [App89, SJ93, Sew92]. A more in depth discussing of these problems are in iGenerational garbage collection, for lazy functional languages, without temporary space leaksj Garbage collection, and memory eOEciency, in lazy functional languages Heap pro ling do not create the garbage Pro ling has for a long time been ....

Patrick M. Sansom and Simon L. Peyton Jones. Generational garbage collection for haskell. In Proc. 6th Int'l Conf. on Functional Programming Languages and Computer Architecture (FPCA'93), pages 106 116. ACM Press, June 1993.

....not describe the overall behavior of objects in most real programs, it may be a useful model for long lived objects. Experimental studies have thus far found few regularities in the behavior of long lived objects that could be used to predict which of them are likely to live longer than others [24, 33, 32, 39]. A total absence of such information is the defining characteristic of the radioactive decay model. Non predictive collectors appear suitable for managing the oldest generations of an otherwise conventional multi generation garbage collector. We have designed a prototype of such a collector for ....

....dynamic type inference [25] nboyer 767 term rewriting and tautology checking (see text) sboyer 781 tweaked version of nboyer Table 2: Six allocation intensive benchmarks. tunately there is little evidence that long lived objects show any strong correlation between age and life expectancy [24, 33, 32, 39]. 7.1 Six fast allocating benchmarks Most programs spend little or no time in the garbage collector, so we have selected six exceptional benchmarks to illustrate the variety of storage behaviors with which a garbage collector must contend. Table 2 lists these programs, which are adapted from 5 of ....

[Article contains additional citation context not shown here]

Patrick M. Sansom and Simon L. Peyton Jones. Generational garbage collection for Haskell. In Conference on Functional Programming Languages and Computer Architecture, 1993, pages 106--116.

....moved to the old heap, i.e. tenured, by the garbage collector, to make separate garbage collection of new and young nodes possible. The criteria for tenuring a node varies between dioeerent generational garbage collectors. The simplest is to tenure all nodes that survive one garbage collection [App89, SJ93, Sew92]; this is called a simple generational collector in this paper. A more traditional method is to tenure nodes that survived some number of minor collections. It is also possible to have dioeerent tenuring ages for dioeerent node types, or even to prevent tenuring completely for some node types ....

....is only updates that can create pointers from old nodes to young nodes. The old to young pointers can be kept in a table, called the exception table, so that the garbage collector can nd these pointers without scanning the old heap. Other methods are to use indirect tables [LH83] linked lists [SJ93] or card marking [WM89] The latter uses a bit eld to mark if a group of nodes (a card) contains any pointers into the new heap. It is easy for the garbage collector to update the exception table when adding nodes to the old generation. The problem is that the mutator updates nodes in the old ....

[Article contains additional citation context not shown here]

Patrick M. Sansom and Simon L. Peyton Jones. Generational garbage collection for haskell. In Proc. 6th Int'l Conf. on Functional Programming Languages and Computer Architecture (FPCA'93), pages 106 116. ACM Press, June 1993.

....the heap is relatively flat in either case. This is also expected the dynamic heap allocator will allocate addresses sequentially from one end of the heap to the other, and most heap addresses are short lived. The garbage collector used (a variant of Appel s generational collector described in [ 10 ] ) does not significantly change the access pattern. Figure 6 shows this. Comparing the same spike and non spike examples used in Figures 4 5, and studying instruction data conflicts carefully, we observe that the patterns of reference and misses are identical for most cases. However, for ....

....memory locations before performing benchmark tests, or ideally use a cache simulator such as ours to measure the frequency of conflicts between different memory locations. It is, of course, unclear whether effects like these have silently affected published results, but Sansom s 1993 FPCA paper [ 10 ] contains one instance of a virtual memory induced spike. It is possible that cache induced spikes have been dismissed as experimental errors in the past or (legitimately) ignored as being irrelevant to the effect under examination. A lesson for compiler writers is that ignoring cacheing effects ....

Sansom PM, "Generational Garbage Collection for Haskell", Proc. FPCA 93, Copenhagen, Denmark, (June 1993), pp. 106--116.

....The marking mark scan garbage collector performs better for all programs mentioned above, except event. For the programs genfft, listcompr, listcopy, sched, transform, and wave4, the marking mark scan collector is about twice as fast as the copying mark scan collector. Sansom and Peyton Jones [SP93] have also described a garbage collector that outperformed copying and compacting collectors. However, this generational garbage collector (as implemented in the Haskell compiler ghc 0.16) was still slower running the benchmarks shown above in Haskell, than was our copying compacting collector ....

P. M. Sansom and S. L. Peyton Jones. Generational garbage collection for haskell. In Proceedings of the Sixth International Conference on Functional Programming Languages and Computer Architecture (FPCA '93), pages 106--115, June 1993.

.... An updatable closure is expensive due to its cost in memory accesses: it is written to memory (created) and (if entered) is read from memory again and later updated with its result (another write operation to memory) Usually a high proportion of the updated closures are never entered again [SP93] and therefore were unnecessary. In the Glasgow Haskell Compiler itself has been measured that about 77 of the updates performed are unnecessary [SP93] Some optimisation techniques try to reduce the number of updates performed. This can be achieved by: early evaluation of strict (demanded) ....

....and later updated with its result (another write operation to memory) Usually a high proportion of the updated closures are never entered again [SP93] and therefore were unnecessary. In the Glasgow Haskell Compiler itself has been measured that about 77 of the updates performed are unnecessary [SP93] Some optimisation techniques try to reduce the number of updates performed. This can be achieved by: early evaluation of strict (demanded) closures: we use strictness analysis together with some transformations to achieve this result (Section 3.6) exposing weak head normal form ....

[Article contains additional citation context not shown here]

Patrick Sansom and Simon Peyton Jones. Generational garbage collection for Haskell. In Functional Programming Languages and Computer Architecture [Fun93b], pages 106 -- 116.

No context found.

P.M. Sansom and S.L. Peyton Jones. Generational garbage collection for Haskell In Proceedings of the ACM conference on Functional Programming Languages and Computer Architecture, Copenhagen, June 1993

No context found.

Patrick M. Sansom and Simon L. Peyton Jones. Generational garbage collection for Haskell. In Hughes [Hughes1993].

No context found.

PM Sansom & SL Peyton Jones [June 1993], "Generational garbage collection for Haskell," in Functional Programming Languages and Computer Architecture, Copenhagen, ACM.

No context found.

P. M. Sansom and S. L. Peyton Jones. Generational garbage collection for Haskell. In R. J. M. Hughes, editor, Record of the 1993.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC